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)

x86
Linux
defect
Not set
normal

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 ....
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.
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.
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.  
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).
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... :)
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).
> 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.  
  
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?
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).
 
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 &#8776; &#8734;.
> 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. 
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.
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.