[Originally reported against Solaris Xprt as Sun bug id #4369307, and fixed in Solaris Xprt by Jay Hobson.] Xprt produces extra dots and tick marks where there shouldn't be any in the Postscript output when using bitmapped fonts. Investigation determined that bitmaps output to ps file were missing pixels because the last buffer was not flushed. (I note the bitmap cache was disabled in the open source Xprt release due to unspecified postscript errors as noted in http://xprint.mozdev.org/bugs/show_bug.cgi?id=1489 - are these those errors or is there another bug still present in the bitmap cache code?)
Created attachment 314 [details] [review] Patch against Solaris version of xc/programs/Xprint/ps/psout.c This is the change applied to the Solaris Xprt sources to fix this bug - it won't apply cleanly to the current open source version, but should be trivial to adapt.
Alan Coopersmith wrote: > I note the bitmap cache was disabled in the open source Xprt release due to > unspecified postscript errors as noted in > http://xprint.mozdev.org/bugs/show_bug.cgi?id=1489 - are these those errors or > is there another bug still present in the bitmap cache code?) Half the number of printers we tested didn't like the PostScript code they got when printing non-ISO-Latin-1 pages (e.g. Japanese, Chinese, etc.) ... and finally we decided to disable the bitmap cache and start to think about a better solution - which resulted in the development of the FreeType font download engine ("Ancalagon") in the current PS DDX. I never looked at the code since then and was ||-close to remove the cache in the next "code cleanup" bug. Now there is the question what we should do with it - there are two options 1. keep the bitmap cache and enable it by default OR 2. Work on a way to download bitmap glyphs as PS Type3 (prevously this wasn't possible because the bitmaps available in the Xserver were already transformed when a font matrix was present... but now the FreeType code can handle bitmap fonts, too - which gives us a way to obtain the untransformed bitmaps and download them to the printer) Advantages/Disadvantages: [1] has the advantage that the code does not rely on the FreeType font engine - the disadvantage is that it cannot handle a transformtion matrix and that it uses a non-standard solution to handle glyphs [2] has the advantage that it uses real, standard PS Type3 fonts to download the bitmaps to the printer and is able to handle a matrix correctly... but it completely depends on the FreeType engine... ;-( Any ideas/suggestions ? Which way would be "better" ?
Created attachment 1002 [details] [review] [FIXED_X11R68x] Patch for Xorg CVS 2004-10-03-trunk
Patch (attachment. 1002) checked-in... /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.426; previous revision: 1.425 /cvs/xorg/xc/programs/Xserver/Xprint/ps/psout.c,v <-- psout.c new revision: 1.5; previous revision: 1.4 Mailing the commit message to xorg-commit@pdx.freedesktop.org... ... marking bug as FIXED.
Comment on attachment 1002 [details] [review] [FIXED_X11R68x] Patch for Xorg CVS 2004-10-03-trunk Requesting approval for X11R6.8.x...
Comment on attachment 1002 [details] [review] [FIXED_X11R68x] Patch for Xorg CVS 2004-10-03-trunk Approved for the X11R6.8.x branch in the 2004-11-17 release-wranglers phone call. Please don't commit it yourself, I'll handle that once the CVS service is available again.
Comment on attachment 1002 [details] [review] [FIXED_X11R68x] Patch for Xorg CVS 2004-10-03-trunk Patch checked-in into X11R6.8.x stable branch: /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.365.2.50; previous revision: 1.365.2.49 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/programs/Xserver/Xprint/ps/psout.c,v <-- psout.c new revision: 1.3.4.2; previous revision: 1.3.4.1 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Mailing the commit message to xorg-commit@lists.freedesktop.org...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.