Closed
Bug 211763
Opened 21 years ago
Closed 20 years ago
Hook up Xft and Xprint server (for a more faithful WYSWYG output)
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jshin1987, Assigned: jshin1987)
Details
(Keywords: intl)
While looking for a way to fix bug 190031 (combining freetype2 - turning truetype fonts to type8 fonts - printing with fontconfig), I came up with this idea. It may or may not work, but it appears easier to direct the 'output' of 'Xft' to Xprint server than bridging the gap between FT2 printing and nsFontMetricsXft without duplicating quite a lot of codes (or some reorganizing). I thought that because an Xprint server is a kind of X server, Xft APIs can be used to 'draw' on it. If that's possible, with soem obvious differences between ordinary X server (for screen) and Xprint server taken care of, we'd be able to utilize a better and more flexible client-side font matching algorithm (used in nsFontMetricsXft) offered by fontconfig in printing with little effort. Keith, is there any restriction in Xft that make Xft APIs not suitable for 'writing' to a higher resolution device like printers? Roland, how does it sound when viewed from the Xprint server side? Any comment or idea? Is it crazy or ....
Assignee | ||
Comment 1•21 years ago
|
||
assigning to myself (I wanted to see who's the owner)
Assignee: printing → jshin
Summary: Hook up Xft and Xprint server (for a more faithful WYSWYG output) → Hook up Xft and Xprint server (for a more faithful WYSWYG output)
Xprint doesn't (currently) support the Render extension, nor do most of the drivers keep a copy of the output bitmap around. That doesn't leave Xft with any good options for drawing. It might be possible to add some primitive Render support to that server, but I'm not sure who would be interested in doing so. And, the results would have to be targeted at a specific resolution as the glyphs transmitted in Render are not outlines, but rather bitmaps. The results of printing these bitmap glyphs at the wrong resolution would be disappointing. I'm interested in getting a FreeType->PostScript conversion library written and I keep hoping someone will manage to hack up Sivan Toledo's code that is currently part of Qt (but could probably be relicensed) or perhaps some other version so that all of the projects which want to generate PostScript could share the common task of getting fonts embedded in the output. I think this is really the only "hard" part of PostScript output for Mozilla. This would permit resolution-independent output as such a library would embed outlines in the PostScript file.
Assignee | ||
Comment 3•21 years ago
|
||
Thanks for your really quick and detailed reply. Somehow I forgot that Render extension is required on the server side. Roland, are you interested in implementing Render extension for Xprint server? In the meantime, I'd better tinker with bug 190031. As for the resolution mismatch, if multiple device contexts can be maintained, we _might_ be able to work around that problem..... As for FT2 to PS conversion (and font embedding/subsetting), it's already implemented in Mozilla [1] (I'm not familiar with Qt code. Nonetheless, it'd be nice to have it wrapped up as a separate library). The output can't be printed with a PS level 1/2 device but with ghostcript so widely used as a host-resident PS interpreterthese days, it's not much of concern. [2] In the past it took a lot of tweaking to make every piece work together (CID-keyed fonts, truetype fonts, OCF fonts, lp/lpr, printer filter, etc), but with recent advances in configuration tools for printing on Unix, it does not any more. [1] Its font selection method is rather close to that of Gfx:Xlib/Gtk code (with XLFD). It's necessary to use fontconfig here and reuse nsFontMetricsXft code as much as possible without copy'n'paste. [2] For CJK users and most of non-Latin 1 users (and the majority of home Unix users regardless of the language they speak), filtering through ghostscript is necessary anyway either because fonts for their scripts are not usually available on the hard disk/ROM of PS printers or because they simply don't have a PS printer.
Render is not required for Xft on a "real" X server; the library will fall back to GetImage/PutImage where necessary. Hmm. When anti-aliasing is disabled, Xft will even use FillRectangle to avoid round trips -- that would work in Xprint, so I guess it would be possible after all, albiet with the same resolution-dependence issues I mentioned earlier. One of the features of the Qt PS font code is that it can be printed on a level-1 device, PostScript has always supported embedded fonts, all it takes is conversion to Type1 or Type3 format which is straightforward for any font supported by FreeType. Once you can embed fonts in the output, the printer driver can reliable generate precisely the same output on the page as on the screen by simply embedding the screen fonts in the output. Qt does this by using the screen font selection routines when printing (iirc), Pango does this by using fontconfig in both places which avoids a dependency on X for printing.
Assignee | ||
Comment 5•21 years ago
|
||
Yeah, I kept forgetting things (I used to run 'Xft applications' on an Xserver without Render extension and remembered a couple of threads on the perf. implication of running Xft appl.'s on a non-Render server). Obviously, we don't need anti-aliasing when printing unless somebody wants to print in tiny 5 point on a relatively low resolution device(300dpi) I think the resolution mismatch is not of great concern because the portability of PS output files gen. by Mozilla is not that important. (Before type1 fonts were widely available for use in TeX, we had the same problem with PS files made from TeX->dvi with 'pk' bitmaps) Being able to print on a level 1 device without filtering is nice, but we can live without it for the reason I gave. Nonetheless, it'd be nice to have a separate library for truetype embedding/subsetting/conversion. That's not a Mozilla issue, though.
Comment 6•21 years ago
|
||
Jungshik Shin wrote:
> Roland, how does it sound when viewed from the Xprint server side?
If I recall it correctly the current plan was to wait for STSF support in
Mozilla while adding support for STSF in the Xprint server at the same time (if
I remember the comments correctly STSF has backwards compatibility for Xft, but
I don't know the exact interactions between both - I am not the one who is
working on that part of Xprint).
Comment 7•21 years ago
|
||
keithp@keithp.com wrote: > Xprint doesn't (currently) support the Render extension, nor do most of the > drivers keep a copy of the output bitmap around. That doesn't leave Xft with > any good options for drawing. It might be possible to add some primitive > Render support to that server, but I'm not sure who would be interested in > doing so. RENDER extension support is planned for version 1.2 or 1.3, depending how much work it is for the single DDXs (note that we need at least three implementations (not counting the XWD/RASTER driver) for RENDER: One of the PostScript DDX, one for thr PDF DDX and one for the PCL DDX (with two codepaths, one for PCL-5 and one for PCL < 5). > And, the results would have to be targeted at a specific resolution as the > glyphs transmitted in Render are not outlines, but rather bitmaps. The > results > of printing these bitmap glyphs at the wrong resolution would be > disappointing. That's why it was suggested to use STSF instead of Xft for that work - (device-specific) font handling belongs to the X server side, not to the client. Then the single DDX (in Xprints case the PostScript or PDF DDX) can manage the font download (as you may have noticed the xprint.org Xprint DDX versions now have font download for all outline fonts --> PS Type3/PS Type1 (PS Type42 coming soon)), all nasty details are hidden away from the application. > I'm interested in getting a FreeType->PostScript conversion library written > and I keep hoping someone will manage to hack up Sivan Toledo's code that is > currently part of Qt (but could probably be relicensed) or perhaps some other > version so that all of the projects which want to generate PostScript could > share the common task of getting fonts embedded in the output. I think this > is really the only "hard" part of PostScript output for Mozilla. This would > permit resolution-independent output as such a library would embed outlines in > the PostScript file. There is already such a library - see gnome-print... :)
Comment 8•21 years ago
|
||
Jungshik Shin wrote: > Thanks for your really quick and detailed reply. Somehow I forgot that Render > extension is required on the server side. Roland, are you interested in > implementing Render extension for Xprint server? Yes, but as I said in comment #7 we actually need 3-4 implementations for the RENDER extension. > In the meantime, I'd better tinker with bug 190031. > > As for the resolution mismatch, if multiple device contexts can be maintained, > we _might_ be able to work around that problem..... What do you mean with that ? > As for FT2 to PS conversion (and font embedding/subsetting), it's already > implemented in Mozilla [1] ... and you know how many people are complaining about the resulting PostScript generated by that piece of code. Unless the issues in the code are fixed it should not be spread more widely (or the maintainer of the new library will have much fun... =:-) > (I'm not familiar with Qt code. Nonetheless, it'd > be nice to have it wrapped up as a separate library). > The output can't be printed > with a PS level 1/2 device but with ghostcript so widely used as a > host-resident > PS interpreterthese days, it's not much of concern. I am sure at least IBM/Sun/HP etc. and a couple of people will disagree here (unless all start shipping GhostScript as part of their core OS distributions (which is very unlikely)) ... [snip] > [2] For CJK users and most of non-Latin 1 users (and the majority of home Unix > users regardless of the language they speak), filtering through ghostscript is > necessary anyway either because fonts for their scripts are not usually > available on the hard disk/ROM of PS printers or because they simply don't > have a PS printer. ... but it is not a good idea to force companies which paid many $$$$$$ for their PostScript printers to use GhostScript before they can use their printer (that sounds at least silly).
Assignee | ||
Comment 9•21 years ago
|
||
> Unless the issues in the code are fixed Yes, there are issues that I want to see fixed (first of all, I want it to use the same font selection/measuring mechanism as is used in Xft code, that is, based on fontconfig), but having to filter the result through gs is the last one if it's an issue at all. > you know how many people are complaining I don't know how many. I've heard from a few at most who are lucky/rich enough to _always_ have PS printers with all the fonts they need for their scripts installed around them. The majority of Mozilla users don't. > companies which paid many $$$$$$ for their PostScript printers to use > GhostScript before they can use their printer (that sounds at least silly). If they have $$$$$$$, why wouldn't they upgrade their printers to brand new PS level 3 devices? If they wouldn't, they have to live with what they have.
Comment 10•21 years ago
|
||
What's required in our Xft code shouldn't be too hard, I don't think. We need an API that will take the usual unicode or ascii strings and hand back a set of fonts and glyphs. We already have the basic bits to do that, we just need to do a little refactoring. What exactly is required on the postscript side? Access to the FT fonts directly? The faces? The glyphs?
Assignee | ||
Comment 11•21 years ago
|
||
I think comment #10 belongs to bug 190031 so that I'm reposting it there. In this bug, I think what we need is just a little impedance matching between Xft output (that is currently targeted at an 'ordinary' Xserver) and Xprint server (treated as a 'dumb' X server instead of an 'intelligent' Xserver with the intimate knowledge of fonts).
Comment 12•21 years ago
|
||
The Render API doesn't provide any way to get outlines from the client through the X server. This means that Xprint will have to deal with bitmap images of the glyphs no matter what glue code you manage to stuff into the Xprint server. The only way to get outlines into PostScript is to avoid the X protocol and generate the postscript natively (or through some helper application). When you talk about an impedance matching library, I suggest you consider that the current SWR ≈ ∞.
Assignee | ||
Comment 13•21 years ago
|
||
> Render API doesn't provide any way to get outlines from the > client through the X server. This means that Xprint will have to > deal with bitmap images I'm aware of this limitation (thanks to you) and have no intention to go beyond/work around that in this bug. By a little impedance matching, I meant nothing special but just setting up a 'device/rendering'(?) context to throw the rendering result(bitmap image) of the _existing_ Xft code at. By using a Xprint server as a 'dumb' Xserver, I meant using it as a 'raster output device' without any knowledge of outline. > to avoid the X protocol and generate the postscript natively Again, this is for bug 190031.
Comment 14•21 years ago
|
||
Sorry for misinterpreting your intention; I thought you wanted to make it work "perfectly" by getting outlines through to the Xprint server. To get bitmap versions of the glyphs into the printer output, there's nothing required aside from disabling anti-aliasing to the Xprint server -- Xft will then generate PolyFillRect to paint glyphs. This means that even existing Xprint servers should work just fine. I don't know how hard it will be to add Render support to Xprint; one requirement of any Render server is support for depth 1, 4, 8, 24 and 32 pixmaps which Xprint may find difficult. Of course, performance without Render will be rather slow, but Render at 1200dpi won't be great either as it doesn't (yet) have any way of transmitting glyphs in a compressed form. Clever tricks inside the Xprint server could recognize sequences of rectangle fills and convert them to Type3 glyphs.
Assignee | ||
Comment 15•20 years ago
|
||
bug 190031 is about to be fixed anytime so that we don't need this.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•