Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Hundreds more printers supported on RISC OS with Gutenprint port update

Published: 30th Jan 2009, 17:56:42 | Permalink | Printable

Gutenprint for RISC OS release 2.3 supports 600 additional printers and printing to CD. More details here.

Click here to visit this news quickie

Previous: How to get RPCEmu Spoon Edition running on an Apple Mac
Next: RISC OS South West show this weekend

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Don't have a need for this myself. However it's good see it being kept up to date Martin.

 is a RISC OS Usersa110 on 30/1/09 9:16PM
[ Reply | Permalink | Report ]

Thats great I downloaded the beta copy a few weeks back and the newer one tonight and paid my contribution. Its great that this has continued and have the newer printers supported.

 is a RISC OS UserHairy on 30/1/09 10:19PM
[ Reply | Permalink | Report ]

Yes, I also noticed this a few days ago, while I was looking for something else: Over an hour to print full colour full page? So this is from faster than to slower than PC printing. How long does simple text output take?

Of course, this is the fault of sloppy writing with the Linux library: Reserve 64Mb all at once when you only need a fraction of that at a time. Attention required there, in Linux/C, and of help to the Linux community too... if only I knew how to help instead of what to do.

 is a RISC OS UserAnon on 2/2/09 5:32PM
[ Reply | Permalink | Report ]

Truly sloppy programmers confuse MB and Mb, too. Last time I looked at Gutenprint, some of its transformations made extensive use of floating point. And memory consumption is hardly ever an indicator of runtime performance. Perhaps you should point your finger elsewhere.

 is a RISC OS Userrjek on 2/2/09 5:46PM
[ Reply | Permalink | Report ]

There's no need to go flaming me! I'm grumbling about the Linux libray Gutenprint uses, not the part MW has written. Anyone can see from the context that I mean megabytes instead of megabits. Excessive and unnecessary memory consumption Does slow performance, particularly on RO machines, where there are bus issue weaknesses. I am NOT pointing my finger at MW, and it is not constructive to flame at constructive critasium.

 is a RISC OS UserAnon on 3/2/09 4:11PM
[ Reply | Permalink | Report ]

What an idiot. You've said you don't know how to fix it, yet you make guesses and assumptions apportion blame on things that are developed _for free_. Wheras Martin is actually _charging_ for his time and produces something which you don't like? Blame Martin, if you must blame someone, maybe he's made an awful port? Maybe your old slow ARM-based machines simply haven't the power to do what's being asked in the time you think they should. (Iyonix is just a historic relic). But there's little point in emptily slagging off things that people have developed and given you for free. You don't deserve to have these things for free.

 is a RISC OS Userimj on 3/2/09 7:50PM
[ Reply | Permalink | Report ]

Typical RO slagging off..

Well done to MW! :@)

 is a RISC OS Userem2ac on 3/2/09 8:21PM
[ Reply | Permalink | Report ]

You've got to realise that Guttenprint is modern software designed to run well on today's typical machines, not ancient creaking relics such as RISC OS systems. A mid range x86 box is well over 100x faster than a StrongARM Risc PC, and even my original underclocked EEE PC is about 4x faster than the Iyonix.

Guttenprint is also designed to run on modern OS's where claiming 64MB is non only a drop in the ocean compared to the overall memory in the machine, but even if there isn't 64MB free the VM system will make it available to the program as an when it is used.

So you've either got to put up with the performance limitations using old underpowered machines, and be grateful someone even thought it was worth the effort to still support them, or it's time to buy something which is capable to doing the job you demand of it.

 is a RISC OS Userdruck on 3/2/09 10:17PM
[ Reply | Permalink | Report ]

Woah, you've really no clue, have you? No criticism from somebody who doesn't know what they're talking about is constructive. It's your computer that's slow, not Gutenprint.

 is a RISC OS Userrjek on 3/2/09 10:37PM
[ Reply | Permalink | Report ]

There's an old saying: "Look after your pennies and your Pounds will look after themselves." The same apples to kilobytes and megabytes. This the principle that produced solid RISC OS code and which enables it to outperform PC even when run onto of their OSes in an emulator.

I am not slagging off anybody (at least until the end of this sentence), particularly not MW, who cites the 64Mb problem in his own description, if any of the ignorant flamers will bother to read it. I have met MW and he's a very pleasant guy.

It's all very well claiming a dozen megabytes here and a dozen there when you're running a few applications, but come to rely on something (as you should), and a few years down the line you'll be running a twenty resource-hungry applications simultaneously and wondering why the damn thing is so slow...

"You've said you don't know how to fix it, yet you make guesses and assumptions..." I know what to do; reduce block of memory assignment where the printer needs only horizontal slices, to, er, horizontal slices. The PC manages it quickly, therefore it must be possible to emulate it quickly. I just don't have the time to commit to it. I am not familar with the nuiances of Linux etc. I could become tackle this in a few weeks if I had a few weeks free, but I do not.

"... apportion blame on things that are developed _for free_." Not apportioning blame, making suggestions for progress. This analysis is free, and if you don't accept that, please feel free to send me a fiver in the post.

I am not going to repeat myself any further. If you don't understand a simple mathematical argument, read it again and think about it before you go flaming off. Eg, "2+2=4" being flamed as "that's wrong because I don't like the colour of the car you drive", does not advance the discussion.

On a different aspect, whatever happened to Postscript, TWAIN, etc?

 is a RISC OS UserAnon on 4/2/09 11:42AM
[ Reply | Permalink | Report ]

"The same apples to kilobytes and megabytes." You really have no idea, do you? And you're still confusing your units. Some people will never learn.

 is a RISC OS Userrjek on 4/2/09 9:22PM
[ Reply | Permalink | Report ]

“I know what to do; reduce block of memory assignment where the printer needs only horizontal slices, to, er, horizontal slices.”

Your naive analysis applied to the RISC OS port's examples results in the conclusion that Gutenprint uses less than one bit per output dot. Does that really sound right to you? Doesn't it seem more likely that they already use a divide and conquer solution and your "suggestion" is redundant ?

Of course its possible to write a driver which runs in a lot less RAM, but it will have worse quality or run much slower and probably both.

“The PC manages it quickly, therefore it must be possible to emulate it quickly”

This doesn't follow. First of all, the hardware is quite different. So for example if the PC can manage fifty times more floating point operations per second then you're going to do most of the heavy weight maths 50x slower than the PC. Or take the CPU cache. The Iyonix for example has only 32kB of cache. So if you've got an algorithm that does random access to 40kB of data (a quite modest size for a LUT in image software), you're thrashing the bus and suddenly the whole CPU is waiting for RAM. On a typical PC that same routine would run from cache, perhaps 10 times faster than the Iyonix even if they were the same CPU speed (and of course the PC will be faster).

But it gets worse - the PC will most likely be running a somewhat modern OS. Even OS X with its laughably naive I/O layer and VM will massively outperform RISC OS. On Linux there are already people trying to optimise for SSDs where there's zero seek delay, finding inefficiencies so small that they were unmeasurable just a few years ago.

“whatever happened to Postscript, TWAIN, etc?”

Postscript is still used at the higher end. It is a full-blown programming language. To run it the printer needs a lot of RAM and a fairly high-end CPU, proportional to the required output resolution (otherwise it will be annoyingly slow). Doing the work in the PC instead thus represents a considerable saving. On a $1500 laser print offering a full Postscript interpreter, including the Adobe license and fonts, is a reasonable decision. On a $100 inkjet printer it isn't going to happen.

TWAIN is the API used to make scanner drivers "drop in" to other applications in Windows and sometimes Mac OS. In the very recent versions of the API there's more thought for other platforms (mainly Linux) but it isn't (as popular idea seems to have it) a platform independent HCI like UVC or EHCI. Each individual "TWAIN compliant" scanner ships with its own OS-specific drivers.

 is a RISC OS Usertialaramex on 7/2/09 6:44PM
[ Reply | Permalink | Report ]

Please stop telling him he's got no idea.

It may be long standing habit of internet forum usage, but being unpleasant to people who make mistakes in otherwise valid posts is neither good reading for the rest of us nor likely to change their opinion. In fact, its neither good reading for the rest of us nor likely to change their opinion even if, as you contest, its not a valid post.

 is a RISC OS UserMonty on 4/2/09 10:40PM
[ Reply | Permalink | Report ]

Monty: I was polite initially, and explanatory, but Anon replied with more nonsense RISC OS fanboy baseless jingoism. As well as being wrong.

 is a RISC OS Userrjek on 5/2/09 9:20AM
[ Reply | Permalink | Report ]

Back when the RISC printing system was developed Archimedies 3xx and 4xx machines didn't even have free enough memory to compose a 300dpi A4 page, so had to split the job up in to strips, rendering the image multiple times and sending the results to the printer before moving on to the next one.

Claiming a buffer large enough for a whole page is a far more efficient way to achieve the task, and makes it easier to support high quality rendering and generate the data for a wider range of printers. As these days 512MB is the absolute minimum in any type of remotely modern computer, a mere 64MB (enough for 2400dpi A4 page), can always be claimed from VM system, so there is absolutely no point making the code more complex to use less memory.

 is a RISC OS Userdruck on 5/2/09 9:43AM
[ Reply | Permalink | Report ]

Sorry, to bring some solid facts along, but maybe it helps in this discussion: The amount of memory Gutenprint claims is not excessive at all, it is mainly a result of the high resolutions we have today. Of course, if that system had been written for RISC OS compromises would have been made in terms of quality in order to save memory but as it stands, the Gutenprint library very cleverly uses just the amount of memory needed to deliver the quality it was designed to deliver.

Druck: Your latest argument goes in the wrong direction because it implies, as others have suggested, that due to VM being available, the library is sloppy about its memory claims. This is not really the case for the bulk of the memory needed. Have you ever figured out how much memory would be needed for a full page buffer at 5760dpi? That would be about 12GB, far too much for any system around.

 is a RISC OS Userwuerthne on 5/2/09 10:22AM
[ Reply | Permalink | Report ]

Martin is to be congratulated on enabling RISC OS users to use the latest printers. On receiving notification of the new Gutenprint drivers I immediately started looking for an upgrade to my existing Epson printer/scanner/copier. I have now found a suitable model and ordered it and am looking forward it.

 is a RISC OS UserDrWhich on 7/2/09 12:02PM
[ Reply | Permalink | Report ]

Can anyone recomend an A3 photo quality printer that can be driven from either an A9Home or an RPC?

 is a RISC OS UserDS1 on 9/2/09 1:40PM
[ Reply | Permalink | Report ]

DS1: aim for an Epson. The Gutenprint Epson drivers are better (as Martin points out on his site). Bear in mind too that an A3 photo-quality page will be twice as large datawise as an A4 ditto, which needs 46MB of memory and takes an hour to print from an Iyonix. On a RPC you're probably looking at leaving it running all night; I've not used an A9, but the performance would be a lot closer to the Iyonix, presumably.

 is a RISC OS Userbucksboy on 9/2/09 3:34PM
[ Reply | Permalink | Report ]

Please note that the memory requirements differ wildly depending on printer model (and obviously resolution). The memory requirements only depend on the width of the printable area, so A3 would only require 1.4 times the memory of A4. As for speed on the A9, I will try and find out - Gutenprint should definitely benefit from the A9's fast memory access.

 is a RISC OS Userwuerthne on 10/2/09 2:57PM
[ Reply | Permalink | Report ]

Thanks bucksboy/Martin. I've got Chris at CJE to see if he can find me an Epson Photo 1400 which I've been recommended.

 is a RISC OS UserDS1 on 11/2/09 1:31PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Spam fighting apps reviewed
    Battle royale!
     20 comments, latest by semore439 on 18/4/04 1:56PM. Published: 11 Jul 2003

  • Random article

  • STD suspends A75, A6 range
    "Legal dispute"
     46 comments, latest by dgs on 16/06/04 10:44AM. Published: 14 Jun 2004

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Unless and until you are willing to produce the evidence to back up your assertions, please cease and desist making these allegations"
    Page generated in 0.2423 seconds.