I’ve encountered a problem whereby pdfTeX generates different subsets of the same font,
containing exactly the same subsetted name.
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.
All the best,
Ross