119102 - Investigate why Xprt PS DDX does not download PostScript fonts

Status: RESOLVED FIXED

(Core Graveyard :: Printing: Xprint, defect)

Description

[Roland Mainz]

I have to look into this in detail (=hardcode debugging) what's going wrong
here:
Mozilla printing the example URL does not cause Xprt to download the hebrew
fonts to the printer.

Requirements for X11R6.5.1 Xprt to download a font to the printer:
- font filename path must contain the string "Type1"
- XLFD font name must contain the string "normal-"
- Xprt only supports *.pfa fonts (no *.pfb)
- PS type1 font file must start with a 0x80 byte

AFAIK this is all given for the fonts in
/usr/openwin/lib/locale/iso_8859_8/X11/fonts/Type1/ - but Xprt still creates
bitmap glyphs in the postscript job instead of downloading the font.

The question is:
WHY ??

Comment 1

[Roland Mainz]

There is a minor bug in X11 sources (I've used X11R6.5.1, X11R6.6 Xprt code is
broken for other reasons) in Xprt PS DDX code which prevents font downloading if
the font name in fonts.dir is mixed case.

However, after fixing that I am getting a print job where the fonts are
correctly downloaded - but the output is broken (wrong charset ?) ... I'll
attach an example job ...

Comment 2

[Roland Mainz]

Attachment: http://www.google.co.il/advanced_search?hl=iw printed with fixed X11R6.5.1 Xprt

It looks that the fonts have been downloaded correctly...
-- snip --
% cat Xpjob_020114112656 | egrep "BeginFont|PS-AdobeFont"
%%BeginFont: lshwb
%!PS-AdobeFont-1.1: LucidaSansHebrew-Bold 001.001
%%BeginFont: lshwr
%!PS-AdobeFont-1.1: LucidaSansHebrew 001.000
%%BeginFont: lshwo
%!PS-AdobeFont-1.1: LucidaSansHebrew-Oblique 001.000
%%BeginFont: Times-Roman
%!PS-AdobeFont-1.0: Times-Roman 001.007
-- snip --
... but the output in sdtimage+GSview looks weired

Comment 3

[Roland Mainz]

Attachment: Fix for Xprt X11R6.5.1 which makes the search for the matching font in fonts.dir case-insensitive

Comment 4

[Roland Mainz]

katakai:
Do you have any clue what's wrong with attachment 64797 [details] ? sdtimage/GSview and
our HP printer only show the english text, but non of the hebrew fonts are
shown... ;-(

Any ideas/hints ?

Comment 5

[Roland Mainz]

Attachment: Better fix for Xprt X11R6.5.1 which makes the search for the matching font in fonts.dir case-insensitive

New patch which tries to fix the broken-downloaded-font issue, too ...

Comment 6

[Roland Mainz]

Attachment: http://www.ibm.com/news/il/2002/01/il_he_news_2002-01-04_blueStorm.html printed with fixed Xprt

http://www.ibm.com/news/il/2002/01/il_he_news_2002-01-04_blueStorm.html printed
with fixed Xprt (X11R6.5.1 + attachment 64829 [details] [diff] [review]).
However the fonts are still broken until I fix the fonts manually in the print
job:
-- snip --
--- Xpjob_020114180546_original Mon Jan 14 18:06:14 2002
+++ Xpjob_020114180546	Mon Jan 14 18:07:09 2002
@@ -677,7 +677,7 @@
 /UnderlinePosition -100 def
 /UnderlineThickness 50 def
 end readonly def
-/FontName /LucidaSansTypHebrew def
+/FontName /lsthwr def
 /PaintType 0 def
 /FontType 1 def
 /FontMatrix [0.001 0 0 0.001 0 0] readonly def
@@ -1546,7 +1546,7 @@
 /UnderlinePosition -100 def
 /UnderlineThickness 50 def
 end readonly def
-/FontName /LucidaSansTypHebrew-Bold def
+/FontName /lsthwb def
 /PaintType 0 def
 /FontType 1 def
 /FontMatrix [0.001 0 0 0.001 0 0] readonly def
-- snip --
After that I am getting the correct fonts (I filed bug 119907 for the broken
layout (not Xprint specific)) ...

Question is (I am not a PostScript expert):
Why is it mandatory to change the font names here ?!

Comment 7

[Roland Mainz]

Attachment: Partial fix

Replacing the use of |PsGetPSFontName| with |PsGetPSFaceName| (new function)
seems to be a solution - however it does not work (yet) because something is
broken oin the Type1 code which parses the FACENAME data.
I am getting the following debug output from the fprintf(stderr, ...) in the
code:
-- snip --
AUDIT: Mon Jan 14 21:43:33 2002: 12706 Xprt: client 1 connected from IP
127.0.0.1 port 33767
file_name='lsthwr', face='LucidaSansTypHebrewes'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwr', face='LucidaSansTypHebrewes'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrewes'
file_name='lsthwr', face='LucidaSansTypHebrewes'
file_name='lsthwr', face='LucidaSansTypHebrewvetic.'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrewes'
file_name='lsthwr', face='LucidaSansTypHebrewes'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='lsthwb', face='LucidaSansTypHebrew-Bold.'
file_name='lsthwr', face='LucidaSansTypHebrew'
file_name='Times-Roman', face='Times-Romanickne.'
AUDIT: Mon Jan 14 21:43:37 2002: 12706 Xprt: client 1 disconnected
-- snip --

It looks that the facename doesn't get properly terminated, some strings have
rubbish at the end ('Times-Romanickne.' instead of 'Times-Roman',
'LucidaSansTypHebrew-Bold.' instead of 'LucidaSansTypHebrew-Bold',
'LucidaSansTypHebrewes' instead of 'LucidaSansTypHebrew' etc.) ...

I'll try to hunt this down sometime this week, but a little help from the
Xserver people would be nice, too ... :)

----

ToDo list:
- Fix the "font name" vs. "font face" issue
- Hook-up a way to call an external helper script/application for converting
non-PFA fonts to PS PFA fonts (PS PFB, TTF etc.)

Comment 8

[Masaki Katakai]

Yes, as you know, the problem is that Xprt looks for fonts by
"lsthwr" not "LucidaSansTypHebrew".

We need to use "LucidaSansTypHebrew" or continue to
use "lsthwr" with the following *aliases*. Anyway,
we need to know /FontName.

/LucidaSansTypHebrew findfont dup length dict
dup 3 -1 roll { 1 index /FID ne 2 index /UniqueID ne
and { 2 index 3 1 roll put } { pop pop } ifelse } forall
dup /FontName /lsthwr put
/lsthwr exch definefont pop

Comment 9

[Roland Mainz]

Attachment: Complete fix

Comment 10

[Roland Mainz]

The fix fetches the correct postscript font name and puts it into the print job.
(Note that the part for xc/lib/font/Type1/fontfcn.c is _mandatory_ or the font
names in the PostScript job will be broken (see comment #7) ...).

Comment 11

[Roland Mainz]

Attachment: http://www.mozilla.org/projects/mathml/start.xml printed with fixed Xprt

MathML example page printed with fixed Xprt (e.g. patch in attachment 65896 [details] [diff] [review]).
Note that no bitmap fonts are used - all fonts (incl. the MathML ones) are
downloaded in the print job (the broken squareroot rendering is a MathML issue,
not related to this bug).

Comment 12

[Roland Mainz]

Comment on attachment 65896 [details] [diff] [review]
Complete fix

I am working on a new patch with some additional fixes/features (like support
for downloading PFB fonts and content-based font type detection...) ...

Comment 13

[Roland Mainz]

Attachment: New patch with some additional fixes and features

More fixes, cleanup and new features:
- Xprt can now download PFB fonts to the printer (as PFA)
- Xprt uses no longer a hardcoded extension for PS Type1 fonts - the type is
determinated based on the "signature" of the file (see magic(4) :)
- Less compiler warnings
- Fixed the issue that the PS DDX's Pseudocolor visual had "0 bits" in the
"significant bits in color specification" (see xdpyinfo output)

Comment 14

[Roland Mainz]

I still have problems printing http://www.google.co.il/advanced_search?hl=iw
with the patched version of Xprt.
1. When I print with 2002-01-23-08-trunk using a (Solaris 7) Xprt which prints
only bitmap fonts layout is OK.
2. When I print with a X11R6.5.1 Xprt (with patch from attachment 66081 [details] [diff] [review]) which
downloads the hebrew fonts I am getting a broken layout. It looks like somehow
the width of the text is not correctly calculated - question os whether this is
a Mozilla bug or a Xprt issue...

I'll attach examples...

Comment 15

[Roland Mainz]

Attachment: http://www.google.co.il/advanced_search?hl=iw printed via Xprt using bitmap glyphs

Comment 16

[Roland Mainz]

Attachment: http://www.google.co.il/advanced_search?hl=iw printed via Xprt using downloaded fonts

Comment 17

[Roland Mainz]

I do not understand why the font download causes this issue (AFAIK the same font
is used - one time it's "embedded" as bitmap glyphs and the 2nd time the Type1
font is downloaded itself to the printer)...
... katakai - do you see what's going wrong here ?

Comment 18

[Roland Mainz]

Attachment: Print preview of http://www.google.co.il/advanced_search?hl=iw using fixed Xprt (attachment 66081)

Screen shot from print preview (Xlib toolkit build; Xprt started with "./Xprt
-ac -pn -fp
/usr/openwin/lib/locale/iso_8859_8/X11/fonts/Type1,/home/gisburn/mathml_fonts/wolfram/Type1/,/usr/openwin/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi/
-audit 4 :12").
The defect described in comment #14 is visible here, too - it looks exactly
like the postscript output with downloaded fonts (attachment 66332 [details]).

Conclustions:
- This is not a bug in the PostScript DDX of Xprt
- This may be a bug in Mozilla5 (which would suprise me as the normal view in
Mozilla is OK - and Xlib and Xprint module are sharing their fontmetrics code)
- This may be a bug in the non-Xprt_PS_DDX parts of the Xserver

Removing the fonts in /usr/openwin/lib/locale/iso_8859_8/X11/fonts/Type1 from
the font path fixes the issue. Fun... ;-(

Comment 19

[Roland Mainz]

Attachment: New patch for X11R6.5.1, more fixes/features

Fixes:
- Printer buildin fonts are now working

Features:
- The PS DDX now includes the job's title
- PS DDX %%Creator line now contains vendor and release id

Comment 20

[Roland Mainz]

Attachment: New patch for X11R6.5.1

Changes:
- Added all available paper sizes/resolutions/etc. to the list of supported
attributes in the PostScript DDX
- Added support for downloading 16bit X11 PFA/PFB fonts (this code is #ifdef'ed
with the |DOWNLOAD_16BIT| CPP symbol. Not tested yet...)

Comment 21

[Roland Mainz]

Attachment: New patch for X11R6.5.1

Changes:
- Added a |void XprintAudit(char *format, ...);| function to write messages to
the audit system. Currently it only logs when fonts are downloaded by the PS
DDX - in the future we should use this feature more extensively (job started,
completed, canceled etc.))
- Minor cleanup

Comment 22

[Roland Mainz]

Attachment: New patch for X11R6.5.1 with fixes for Linux

Changes:
- Added some fixes to roll-out a Linux test build
- Now uses /usr/bin/lpr instead of /usr/bin/lp on Linux to spool jobs
- Fixed some build issues to get the stuff compiling on SuSE 6.4

Comment 23

[Roland Mainz]

Comment on attachment 74656 [details] [diff] [review]
New patch for X11R6.5.1 with fixes for Linux

I created a Linux x86 distribution using this patch, see
http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_004.tar.gz

Comment 24

[Roland Mainz]

Attachment: Patch for X11R6.6

Changes:
* Ported patch to X11R6.6, all previous fixes for PS DDX are now working in
R6.6, too...
- Added resolutions 100, 120, 150, 180, 200, 240, 360, 400
- Changed PS identifier from "%!PS-Adobe-3.0 EPSF-3.0" to "%!PS-Adobe-3.0" to
make GhostScript happy (no warning dialogs anymore)
- Disabled bitmap glyph cache to get rid of the PostScript errors (need a
postscript guru to take a look at the generated code to figure-out what is
going wrong here)

Comment 25

[Roland Mainz]

Attachment: New patch for X11R6.6

Changes:
- Replaced the global "pagenum" in psout.c with a pagenum var in the PsOut
context. This fixes the problem that parallel running clients overwrite the var
which causes random page numbers in the PostScript jobs

Issues found:
- I adoped my "xptest" to simulate any number of clients running in parallel on
the Xprt server. Beyond 4 parallel clients there are minor differences in job
size which should not be there (all jobs should have the same size), running
the tool simulating 128 clients makes Xprt exit with various errors or crashes.
Fun... ;-(

Comment 26

[Roland Mainz]

Another issue:
It looks that print-to-file is completely busted on the x86 platforms (and maybe
all other little-endian platforms).
For example the reply created in XpFinishDocData() (see
xc/programs/Xserver/Xprint/Util.c) is correctly filled-in, swapped and passed
to  WriteToClient() - but the client only sees junk (for example the status code
is |0| on the server side but |8| on the client side).

The real fun starts when I compile the server with -O2 on my Linux machine -
then the garbage send to the client contails even corrupted data length fields
which results in a client crash... ;-(

The SPARC version of the code works just fine...

Comment 27

[Roland Mainz]

The issue above (comment #26) seems to be a client-side issue when the
threaded-version of XprintUtil is used - the fork()-based print-to-file consumer
code works fine.
I filed bug 134570 ("Print-to-file not working with threaded XprintUtil") to use
the fork()-version in Mozilla for now...

Comment 28

[Roland Mainz]

The X11R6.6-based Xprt seems to have a flaw:
When the client side crashes the Xprt server sometimes dies with the following
message:
-- snip --
AUDIT: Tue Apr  2 16:53:22 2002: 23714 Xprt: client 1 connected from IP
141.50.42.191 port 49172
AUDIT: Tue Apr  2 16:53:27 2002: 23714 Xprt: client 1 disconnected

Fatal server error:
Freeing resource id=40400000 which isn't there

execution completed, exit code is 1
-- snip --

The stack trace looks like this:
-- snip --
AUDIT: Tue Apr  2 16:58:39 2002: 15876 Xprt: client 1 connected from IP
141.50.42.191 port 49222
AUDIT: Tue Apr  2 16:58:44 2002: 15876 Xprt: client 1 disconnected
signal ABRT (Abort) in _libc_kill at 0xff21a538
0xff21a538: _libc_kill+0x0008:  bgeu    _libc_kill+0x30
Current function is FreeResource
  497           abort(); //FatalError("Freeing resource id=%X which isn't
there", id);
(/opt/SUNWspro/FD7/bin/../YNH/bin/sparcv9/dbx) where
  [1] _libc_kill(0x0, 0x6, 0xff235e10, 0x0, 0xffffffff, 0x0), at 0xff21a538
  [2] abort(0xff235e10, 0x40400000, 0x16, 0x0, 0x0, 0x0), at 0xff1b95b8
=>[3] FreeResource(id = 1077936128U, skipDeleteFuncType = 24U), line 497 in
"resource.c"
  [4] FreeXpClient(pXpClient = 0x79b0f0, freeResource = 1), line 1369 in
"xprint.c"
  [5] XpFreeClient(data = 0x79b0f0, id = 1077936128U), line 1330 in "xprint.c"
  [6] FreeClientResources(client = 0x7189a8), line 679 in "resource.c"
Symbol *0xf0d678
dbx: duplicate type definition (3,13), assuming int {assumed}, sclass 10:
/home/gisburn/package-builds/x11/r66/build/xc/programs/Xserver/Xprt:dispatch.c
stab #32988 _pthread_attr:T(14,82)=s4__pthread_attrp:(3,13)=*(0,20),0,32;
  [7] , at 
  [8] Dispatch(0x1, 0xffbee5e8, 0xffbee6dc, 0x0, 0x0, 0x0), at 0xef1a4
  [9] main(argc = 8, argv = 0xffbee6dc), line 364 in "main.c"
(/opt/SUNWspro/FD7/bin/../YNH/bin/sparcv9/dbx) 
-- snip --

Comment 29

[Roland Mainz]

Comment on attachment 76122 [details] [diff] [review]
New patch for X11R6.6

Created a Linux x86 binary tarball from this patch, see
http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_005.tar.gz

Comment 30

[Roland Mainz]

Attachment: Output of "lpc status" from the LPng print system on Debian Linux

Feedback from debian users:
They use "LPng" instead of the normal Linux print system - the output of "lpc
status" is different. This breaks the auto-lookup of installed printers in a
system.

Fix:
Run "lpc status" once per print system and filter both cases:
-- snip --
# 'normal'
% lpc status | /usr/bin/awk '/:$/ && !/@/ { print $1 }' | sed -e /:/s/// | sort

# 'LPng'
% lpc status | /usr/bin/awk '/@/ && !/:/ { split( $1, name, "@" ); print
name[1]; }' | sort
-- snip --

Comment 31

[Roland Mainz]

Attachment: New patch for X11R6.6

Changes:
- Added support for LPng (Debian Linux)
- Made the error in comment #28 non-fatal to avoid that the server exists

Comment 32

[Roland Mainz]

Comment on attachment 80144 [details] [diff] [review]
New patch for X11R6.6

I forgot to quote one change:
- If the default configuration directory and the $XPCONFIGDIR dir are
non-existant the server will now refuse to start (e.g. no complains when Xprt
behaves wrong (like gfx-only fonts etc.) due missing config files =:-)

Comment 33

[Roland Mainz]

Attachment: New patch for X11R6.6 (20020425)

Changes:
- Added workaround for bug 140030 ("Setting number of copies causes too many
copies to print"). The workaround used here disables the use of the /NumCopies
command until we choose a final solution for bug 140030.

Comment 34

[Roland Mainz]

Attachment: Patch (20020518) to previous diff (20020425)

Changes:
Rewrote some functions in PsText.c to make it easier to plug&play the PS Type42
download code. The new code should speed-up rendering of bitmap glyphs a lot,
too...

Comment 35

[Roland Mainz]

Attachment: Full patch (20020518) for X11R6.6

Comment 36

[Roland Mainz]

Follow-up to this bug is now the CVS at http://xprint.mozdev.org/ ; I am "done"
with splitting-up the large patch here into single bugs, filing single patches
for them and creating a CVS tree based on the X11R6.6 sources and all the
patches from the bugs...

Comment 37

[Bjørn Kutter]

roland - is this bug report still valid or can it be closed?

Comment 38

[Roland Mainz]

Bjørn Kutter wrote:
> roland - is this bug report still valid or can it be closed?

No, this bug can be closed...

... marking bug as FIXED, follow-up is http://xprint.mozdev.org/ ... :)