Quote:

There are no bitplanes.
CyberGraphX system adds an ability to work with abstract bitmap objects. Their internal structure is private to the system, they can hold truecolor and chunky colormapped data.
graphics.library is able to distinguish these bitmaps and handle them with the same calls as before. These bitmaps are passed as struct BitMap with some black-box contents which shoud not be interpreted by an application.
Also graphics.library understands old planar bitmaps if someone supplies them, but this is kept only for compatibility.

Quote:

So there are no bitplanes in there !?

Quote:
Yes, exactly.
Quote:
Probably. The driver question is open here.

Quote:

graphics.library is already chipset-independent for years. CyberaphX and Picasso96 for AmigaOS and HIDD stack for AROS do their job well.
Besides, this is not the topic.

I think what sonicamiga is saying is that we have an AROS "virtual printer" that, from a programmers perspective, we can print all bitamps, fonts and vector drawings on. This data is then sent to the user selected printer driver (hopefulley a CUPS driver). This last step is the tricky bit.





Quote:

graphics.library...
Should it not be graphics chipset independent ?, nowadays I mean. Yea yea compatibility.. too many variables/fields/structures (and their respective APIs) that are (old Amiga) chipset dependent, and thus not very elegant.

If we speak about good printing subsystem...
Well, conventional AmigaOS printing system and even TurboPrint suffer from a big drawback: they are unable to use possibilities offered by modern printers to render the picture inside the printer, not using host CPU for it.
What does AmigaOS offer: create a struct BitMap and print it out. TurboPrint does nothing more, it just adds support for truecolor bitmaps.
What do Windows and MacOS offer: there's a concept of "Device contexts". Device context is some abstract entity on which we can draw graphics (something like struct RastPort in graphics.library). Device context does not necessarily represent a screen, it can represent also a printer.
An application can do various operations on the device context: draw shapes, text, fill regions, perform blits, etc. The same set of functions that we have in graphics.library for operating on RastPorts.
When an application finishes creating a page it uses an OS function to "visualize" the context. In case of printer context this operation performs sending data to the printer.
What it gives: if a modern printer is used (PCL, PostScript, etc) instead of rendering a bitmap OS can simply record a sequence of performed actions in the form of printer's language. This results in a shorter data stream and much faster printing.
I suggest that we should develop such a system. Would be nice if it's portable to other Amiga-derived OSes.
We could, for example, have some kind of printergfx.library which does the same things as graphics.library does for screen. Of course the new system should be backwards compatible with original AmigaOS API and TurboPrint.
I don't know how well CUPS fits into it.

Quote:

Question would be, would it be worth it in developer's time and effort to write something from nearly scratch vs just porting CUPS? Odds are, we would want it to be compatiable with CUPS so our AROS boxes can access the printer(s) on the LAN as I doubt one would buy a printer just for the AROS box.

Dammy

Wouldnt the best thing be to make it more simple to port linux printer drivers, make some good how to guide, and use some kind of printer.hidd. Would be very Aros-like.

Quote:


What about a bounty about writing an AROS printing system that takes advantage of CUPS printer drivers. This could be done. Some kind of wrapper ? It'd be even nicer if we could use Windows printer drivers on AROS (LOL!) but this would probably be legally unattainable. Having said that, I just googlef "freeware printer drivers' and found many freeware windows drivers eg.http://www.dirfile.com/drivers_printers-1.htm

This raises the question: "Should AROS printer drivers be dependant on another OS's printer driver development".

Answer No. but lets say we used linux printer drivers and linux died out next year, we could just start developing our own linux style drivers anyway.