Bug 690724

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.