> 1) Our own PS generator > 2) A driver based on GnomePrint > > I'm working on making #2 functional again. If > wxWindows can have a Gnome dependency, I *highly* > recommend using libgnomeprint and libgnomeprintui > versions 2.2.x
Dependancy on the infamous 200 Gnome libraries is currently no option for wxWindows. It may be less of a problem for a "single app" project like AbiWord. > So, our printing is done in a fashion very > similar to on-screen drawing, or how your > "device contexts" work. (..) > Pretty much all of these have a 1:1 mapping > onto PS and PDF drawing operations. Yes I know, we alredy can print to PS, it's just not yet optimal. > Now, one can't use Pango to print, at least > not yet. Well, we do :-) I just tell the FreeType backend of Pango to produce outlines of the rendered text and write these to the PS file. I have to work on scaling, but the text is there including CJK without having to embed 7.5Mb fonts in the PS file. > so that we can embed the font directly in the > PS output, instead of merely referencing it by name. > See any PS or PDF manual for what that means. I actually read both and I'm fairly familiar with both concepts. The problem is that you would have to embed megabytes of data for a Japanese font. If I am not mistaken, OpenOffice and Qt are both able to embed only individual glyphs to avoid that problem. Unfortunately, this is beyond my knowledge of PostScript. > Now, we use Xft2/FontConfig if possible to get > the font metrics and font files themselves. Yes, I know. But what about ligatures or more exotic scripts? You need shapers for them or the text won't look ideal. Everyone can print "Hello" in PostScript :-) > Xft2/Fontconfig is installed and have a way > to convert text to UTF8 or UCS4, We have both in wxWindows. > it's pretty trivial to craft a fairly > functional PS driver device context. I know since I have written most of the current PS driver for wxWindows, but "fairly" funtional is not always enough. Once again, I still hesitate to throw away Pango until I see any real reason to do so. Since AbiWord has much more experience with printing issues, I am raising the issue here. BTW, does AbiWord handle the problem that text can have a differnt size/length depending on the resolution? Printers obviously have far higher resolutions and this can in rare cases affect line break algorithms. > > although it doesn't really matter as ar as > > my question is concerned, but I am one of > > the main authors of the wxWindows library, > > which the very early AbiWord team considered > > to use instead of writing all the platform > > dependent GUI code for each platform. Since > > both projects rather often have to address > > similar problems, it might have been easier > > for both to cooperate, but that didn't happen > > for whatever reason. > > Never mind, as the main and almost only > > GTK and GTK2 developer of wxWindows, I am > > currently investigating new ways to support > > printing under wxWindows. AbiWord's and > > wxWindows's graphics and printing system > > are almost identical in design, with what > > is called a "device context" in wxWindows > > and "GR_something" in AbiWord which I got > > from CVS HEAD a few days back. I am posting > > here, because I could not find something > > like a design document for the printing > > system and the code is totally cluttered > > with #ifdefs for Pango and Xft. Am I right > > that under AbiWord's new GTK2 version, text > > is rendered on screen using GTK2's Pango, > > but that AbiWord uses Xft to find and work > > with fonts for PostScript output? > > What version requirements do you have for > > both libararies? I have a stock SuSE 8.1 > > which is the newest you can get, but maybe > > I'll need the BRAND newest code for either > > of FreeType, XRender, Xft, Pango, FriBidi > > or even something else before I can start > > to compile the system. > > > > Thanks for any info, > > > > Robert -- Robert Roebling, MD <[EMAIL PROTECTED]>
