Hi all.
I’ve encountered a problem whereby pdfTeX generates different subsets of the same font, containing exactly the same subsetted name.
On 1 Oct 2018, at 8:36 am, Karl Berry
mailto:karl@freefriends.org> wrote: Hi Ross,
If you feel like posting the issue to the ntg-pdftex list, or coming up with a patch yourself, so much the better. A simpler test using plain TeX that just typesets two characters in two different fonts and creates the problems would be helpful, too.
This coding exhibits the problem.
%%% test-duplicate-fonts.tex %%%
\font\fonti=fxlri-7alt
\font\fontii=fxlri-7letters
\font\fontiii=fxlri-7letters at 11pt
{\fonti \char"03}
{\fontii A B C}
{\fontiii A D E} \bye
%%%%% end of test-duplicate-fonts.tex %%%
Using pdf fonts to see the names of embedded fonts, one gets:
name type emb sub uni prob object ID ------------------------------------ ----------------- --- --- --- ---- --------- SAMSAA+LinLibertineI7 Type 1 yes yes yes 4 0 SAMSAA+LinLibertineI7 Type 1 yes yes yes 5 0 SDXKYB+CMR10 Type 1 yes yes yes 6 0
Where the 1st two entries are seen to be identical.
Running Preflight checks, this duplication results in error reports as in the image. (BTW, I was using a different filename to the above coding.)
I think the issue is related to having 2 different fonts (here fxlri-7alt and fxlri-7letters from the newtx fonts ) using characters from the same base font (here LinLibertineI7 ). But this is not an error in itself.
The issue must lie with how the subsetting prefix ‘SAMSAA’ is generated. Surely if the same prefix has already been used with an instance of the same font, then the next instance should increment it (e.g., to SAMSAB or SAMSAC or …., say) until a unique name is achieved.
It is important to get this fixed, else many otherwise perfectly fine documents will fail Preflight validation checks, for modern PDF standards. one can argue that the validator is wrong ... the subsetted basefont
On 10/3/2018 12:57 AM, Ross Moore wrote: that is used is the same but it's accessed with different encodings which refer to the same subsetted font 14 0 obj << /Type /FontDescriptor /FontName /YYQYMX+LinLibertineI7 /Flags 4 /FontBBox [ -678 -312 6603 893 ] /Ascent 696 /CapHeight 660 /Descent -232 /ItalicAngle -12 /StemV 76 /XHeight 429 /CharSet( /A /B /C /Xi) /FontFile 15 0 R >> endobj 10 0 obj << /Type /Encoding /Differences [ 4 /Xi ] >> endobj 6 0 obj << /Type /Font /Subtype /Type1 /BaseFont /SDXKYB+CMR10 /FontDescriptor 12 0 R /FirstChar 49 /LastChar 49 /Widths 8 0 R >> endobj 4 0 obj << /Type /Font /Subtype /Type1 /BaseFont /YYQYMX+LinLibertineI7 /FontDescriptor 14 0 R /FirstChar 4 /LastChar 4 /Widths 11 0 R /Encoding 10 0 R >> endobj 5 0 obj << /Type /Font /Subtype /Type1 /BaseFont /YYQYMX+LinLibertineI7 /FontDescriptor 14 0 R /FirstChar 65 /LastChar 67 /Widths 9 0 R >> endobj a larger test: \font\fonti =fxlri-7alt \font\fontii=fxlri-7letters {\fonti \char"04}\par {\fontii A B C}\par \count99=0 \def\foo{ \char\count99 \advance\count99 1 \ifnum\count99<256 \expandafter\foo \fi} {\font\fonta=texnansi-qplr \fonta \foo}\par {\font\fonta=ec-qplr \fonta \foo}\par {\font\fonta=qx-qplr \fonta \foo}\par {\font\fonta=t5-qplr \fonta \foo}\par {\font\fonta=qx-qplr-sc \fonta \foo}\par \bye this will still use one font resource with > 256 characters (and a bit bogus encoding in the pfb blob which actually can be StandardEncoding) so it's a rather old situation i think ... and changing that will demand big changes (so not something done quick as one never knows what side effects occur) e.g. one font resource per subset (so larger files too) (the same in luatex but there one will normally use wide fonts which don't have that problem and there are subtlke differences between the engines) (acrobat X - i have no newer version - preflights ok) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------