I see a blank page with felltypes-test.pdf with gs -sDEVICE=x11 felltypes-test.pdf -c quit (GPL Ghostscript 8.70 (2009-07-31)) Acroread 9 shows it bad Acroread 8 shows it bad Acroread 7 shows it OK xpdf 3.02 shows it OK mupdf mupdf-2009-07-01-linux-x86 shows it OK This pdf uses FellTypes, the OpenType with postscript oulines and advanced typographic features version at http://iginomarini.com/fell/wp-content/uploads/imfellclass28.zip (note not truetype) which have an unusual unitsPerEm of 2048
Created attachment 5320 [details] felltypes-test.pdf
Confirmed. Evince and mupdf show the page. Ghostscript displays a blank page. MuPDF complains: warning: object id (32 0 R) out of range (0..31)
Actually a font problem, not an x11 problem
This problem is a regression. The text appears OK before rev. 3274. The text renders as small dots before rev. 3570. The text disappears completely afterwards.
>This problem is a regression. >The text appears OK before rev. 3274. >The text renders as small dots before rev. 3570. >The text disappears completely afterwards. Alex can you tell me how to find these revisions in the gs-cvs archives please ? These predate the revision as part of the subject (and use of Subversion) and I'm unable to locate any likely changes by searching the archive manually.
This is the rev. 3247 http://ghostscript.com/pipermail/gs-cvs/2002-October/002503.html and this is the rev. 3570. http://ghostscript.com/pipermail/gs-cvs/2003-January/002860.html You can get the commit date as: svn log -r XXXX gs and search the list by the date. You can also get the diff to the previous revision as: svn diff -r XXXX:YYYY gs
Thanks Alex, I have them now. At least I know where to look for the problem....
Disabling the patch 3247 and some later code related to leaf matrix makes the text visible. Index: gs/base/gxchar.c =================================================================== --- gs/base/gxchar.c (revision 10016) +++ gs/base/gxchar.c (working copy) @@ -371,7 +371,7 @@ if (penum->width_status != sws_none && penum->width_status != sws_retry) return_error(gs_error_undefined); - if (penum->fstack.depth > 0 && + if (penum->fstack.depth > 0 && false && penum->fstack.items[penum->fstack.depth].font->FontType == ft_CID_encrypted) { /* We must not convert advance width with a CID font leaf's FontMatrix, because CDevProc is attached to the CID font rather than to its leaf. @@ -1448,7 +1448,7 @@ pfont = pfsi->font; gs_matrix_multiply(&pfont->FontMatrix, &pfsi[-1].font->FontMatrix, &mat); - if (pfont->FontType == ft_CID_encrypted) { + if (pfont->FontType == ft_CID_encrypted && false) { /* concatenate the Type9 leaf's matrix */ gs_matrix_multiply(&mat, &(gs_cid0_indexed_font(pfont, pfsi->index)->FontMatrix), &mat);
Disabling the patch causes the file badcharsize.pdf from bug #576591 to revert to the incorrect behaviour which was fixed by that patch (no surprise). It looks like the actual problem is the font matrix of the descendant font [0.001 0 0 0.001 0 0]. This appears to be generated by Ghostscript internally, the font in the PDF file has a matrix of [0.000488281 0 0 0.000488281 0 0] which is the matrix which is stored in the parent CIDFont. There's no indication that any of the descendant fonts are created (from the PDF file) with a matrix, which is why I assume GS is creating a default matrix. Unfortunately it looks like this is the wrong matrix, at least in this case. Substituting with the identity matrix ([1 0 0 1 0 0]) results in the text appearing, though the spacing is odd.
This patch partially fixes the problem. The character spacing is still incorrect, and at least one other file (badcharsize.pdf) displays some text *much* too large when this patch is applied. Plenty of investigation still to do I think.
Here is another example: use fontforge Executable based on sources from 17:32 GMT 14-Sep-2009-ML. and make a pdf with FellType font FeDPrm27C.otf pr-IM_FELL_Double_Pica_PRO_Roman.pdf: fontforge Fonts name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- Times-Bold Type 1 no no no 45 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 5 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 8 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 11 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 14 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 17 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 20 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 23 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 26 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 29 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 32 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 35 0 IM_FELL_Double_Pica_PRO_Roman Type 1 yes no no 38 0 The font has em size : 2048 , no problem with acroread 9
The CFF fonts in supplied PDF is a CFF CIDFont. The Top DICT (corresponds to FontType 9 CIDFont) has a FontMatrix = [0.000488281 0 0 0.000488281 0 0], and Font DICT (corresponds to FDArray font) does not have it. Current ghostscript's CFF parser (gs_cff.ps) inserts FontMatrix of [0.001 0 0 0.001 0 0] into FDArray fonts when they do not have it, as a result this font became a very small size we cannot see - this is what is happening right now. There is no explicit description what to do with FontMatrix of CFF CIDFont in Adobe tech note #5176 (CFF Spec), but with Ken's help we figured out this is what it should be: 1) If both Top DICT and Font DICT does _not_ have FontMatrix, then Top DICT = [0.001 0 0 0.001 0 0], Font DICT = [1 0 0 1 0 0]. (Or, Top DICT = (absent), Font DICT = [0.001 0 0 0.001 0 0] then let '/CIDFont defineresource' make Top DICT = [0.001 0 0 0.001 0 0], Font DICT = [1 0 0 1 0 0].) 2) If Top DICT has FontMatrix and Font DICT doesn't, then Top DICT = (supplied matrix), Font DICT = [1 0 0 1 0 0]. 3) If Top DICT does not have FontMatrix but Font DICT does, then Top DICT = [1 0 0 1 0 0], Font DICT = (supplied matrix). (Or, Top DICT = (absent), Font DICT = (supplied matrix) then let '/CIDFont defineresource' make Top DICT = [0.001 0 0 0.001 0 0], Font DICT = (supplied matrix 1000 times larger). I think this is better.) 4) If both Top DICT and Font DICT _does_ have FontMatrix, then Top DICT = (supplied matrix), Font DICT = (supplied matrix). This change should solve at least some of the problems we have. Acrobat 8, 9 and Apple Preview shows spacing problems with this file, we may need to investigate more on that.
Created attachment 7069 [details] patch Implement correct defaults for /FontMatrix attribute in composite CFF font following the analysis by Ken and Masaki.
The patch has been committed as a rev. 11980.