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.

sa110 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.

Hairy 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.

Anon 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.

rjek 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.

Anon 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.

imj on 3/2/09 7:50PM
[ Reply | Permalink | Report ]

Typical RO slagging off..

Well done to MW! :@)

em2ac 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.

druck 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.

rjek 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?

Anon 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.

rjek 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.

tialaramex 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.

Monty 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.

rjek 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.

druck 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.

wuerthne 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.

DrWhich 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?

DS1 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.

bucksboy 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.

wuerthne 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.

DS1 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

South East 2008 show round up
News from the event in the south of the UK

42 comments, latest by diomus on 9/11/08 8:45PM. Published: 19 Oct 2008

Random article

movspclr.co.uk update flurry
New freeware including fault reporting Bugz

Discuss this. Published: 2 Jun 2002

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"I must put drobe.co.uk on the blacklist of UN USER FRIENDLY ACORN WEBSITES"
Page generated in 0.077 seconds.