[tex-k] dvips font issue with embedded graphics file

[Roderick Johnstone]

Hi

I have an issue with fonts in some graphics files embedded by dvips that
are not displaying correctly in the postscript written by dvips. The
issue is fixed using dvips -j0.

Not sure if this is a dvips bug or a problem with my graphics file. I
could provide a simple test case if anyone could help.

Thanks

Roderick Johnstone

[Reinhard Kotucha]

Post by Roderick Johnstone
Hi
I have an issue with fonts in some graphics files embedded by dvips
that are not displaying correctly in the postscript written by
dvips. The issue is fixed using dvips -j0.
Not sure if this is a dvips bug or a problem with my graphics
file. I could provide a simple test case if anyone could help.

Yes, a simple test case would be helpful.

Regards,
Reinhard

[Pierre MacKay]

Post by Roderick Johnstone
Hi
I have an issue with fonts in some graphics files embedded by dvips that
are not displaying correctly in the postscript written by dvips. The
issue is fixed using dvips -j0.
Not sure if this is a dvips bug or a problem with my graphics file. I
could provide a simple test case if anyone could help.
Thanks
Roderick Johnstone

If the fonts are contained in the graphics file, DVIPS cannot reach in
to manage and revise any subsetting done by the graphics program. There
is no guarantee that DVIPS would even have access to those fonts, but in
your instance it clearly did. So DVIPS did its own subsetting, and the
arbitrary list of subset references did not happen to be the same as the
one embedded in the graphic. When you use -j0, you turn off subsetting
altogether and embed the entire font in the PS file. That leaves only
the subset already supplied for the graphics file, and there is no
confusion. For many years I had to do that with the Monotype Superfont
for Times Roman, because its subsetting conflicted with another Times
Roman font in the same document.

Pierre MacKay

[Reinhard Kotucha]

Post by Pierre MacKay

Post by Roderick Johnstone
Hi
I have an issue with fonts in some graphics files embedded by dvips that
are not displaying correctly in the postscript written by dvips. The
issue is fixed using dvips -j0.
Not sure if this is a dvips bug or a problem with my graphics file. I
could provide a simple test case if anyone could help.
Thanks
Roderick Johnstone

If the fonts are contained in the graphics file, DVIPS cannot reach in
to manage and revise any subsetting done by the graphics program.

Does dvips make any attempt to subset fonts in external graphics files
at all unless they contain something described in section 5.1.6. of
the dvips manual?

Regards,
Reinhard

[Tom Rokicki]

I do not believe it does.

On Fri, Jan 13, 2012 at 4:27 PM, Reinhard Kotucha

?> > Hi
?> >
?> > I have an issue with fonts in some graphics files embedded by dvips that
?> > are not displaying correctly in the postscript written by dvips. The
?> > issue is fixed using dvips -j0.
?> >
?> > Not sure if this is a dvips bug or a problem with my graphics file. I
?> > could provide a simple test case if anyone could help.
?> >
?> > Thanks
?> >
?> > Roderick Johnstone
?> >
?> >
?> If the fonts are contained in the graphics file, DVIPS cannot reach in
?> to manage and revise any subsetting done by the graphics program.
Does dvips make any attempt to subset fonts in external graphics files
at all unless they contain something described in section 5.1.6. of
the dvips manual?
Regards,
?Reinhard
--
----------------------------------------------------------------------------
Reinhard Kotucha ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Phone: [phone]
Marschnerstr. 25
D-30167 Hannover ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------

[Pierre MacKay]

Post by Reinhard Kotucha

Post by Pierre MacKay

Post by Roderick Johnstone
Hi
I have an issue with fonts in some graphics files embedded by dvips that
are not displaying correctly in the postscript written by dvips. The
issue is fixed using dvips -j0.
Not sure if this is a dvips bug or a problem with my graphics file. I
could provide a simple test case if anyone could help.
Thanks
Roderick Johnstone

If the fonts are contained in the graphics file, DVIPS cannot reach in
to manage and revise any subsetting done by the graphics program.

Does dvips make any attempt to subset fonts in external graphics files
at all unless they contain something described in section 5.1.6. of
the dvips manual?
Regards,
Reinhard

That was my point, I don't think it can do so or does do so, but the
phenomenon mentioned by Roderick Johnstone matches the effect of
conflicting subsets that I have already encountered, particularly when
using graphics generated by Illustrator. The confusion may arise in my
case owing to the use of a distiller such as ps2pdf or Adobe on-line
distiller. I wonder whether Roderick Johnstone's problem involves that
additional stage. In any case, I have learned to avoid using fonts with
the same foundry name in both included non-TeX graphics and TeX text.
For one thing, they never look quite the same, so an explicit change of
font seems a better idea.

Pierre MacKay

[Roderick Johnstone]

Post by Pierre MacKay

Post by Roderick Johnstone

Post by Pierre MacKay

Post by Roderick Johnstone
Hi
I have an issue with fonts in some graphics files embedded by

dvips that

Post by Pierre MacKay

Post by Roderick Johnstone
are not displaying correctly in the postscript written by

dvips. The

Post by Pierre MacKay

Post by Roderick Johnstone
issue is fixed using dvips -j0.
Not sure if this is a dvips bug or a problem with my graphics

file. I

Post by Pierre MacKay

Post by Roderick Johnstone
could provide a simple test case if anyone could help.
Thanks
Roderick Johnstone

If the fonts are contained in the graphics file, DVIPS cannot

reach in

Post by Pierre MacKay
to manage and revise any subsetting done by the graphics program.

Does dvips make any attempt to subset fonts in external graphics files
at all unless they contain something described in section 5.1.6. of
the dvips manual?
Regards,
Reinhard

That was my point, I don't think it can do so or does do so, but the
phenomenon mentioned by Roderick Johnstone matches the effect of
conflicting subsets that I have already encountered, particularly when
using graphics generated by Illustrator. The confusion may arise in my
case owing to the use of a distiller such as ps2pdf or Adobe on-line
distiller. I wonder whether Roderick Johnstone's problem involves that
additional stage. In any case, I have learned to avoid using fonts with
the same foundry name in both included non-TeX graphics and TeX text.
For one thing, they never look quite the same, so an explicit change of
font seems a better idea.
Pierre MacKay

Hi

Thanks for your attention to this issue. Here are some more details.

I'm using texlive-2011 on Fedora 16 x86_64 from the packages made
available by Jindrich Novy.

I generated a graphics postscript file from a package called pgplot, and
incorporated that into a latex document.

What I find is that when using the "roman" font in pgplot and the latex
"times" package the postscript generated by dvips has some missing
symbols in the axis labels of the graphics, eg superscript minus sign is
missing. If I further process the ps file through ps2pdf the minus sign
is still missing and the spaces between words in the axis labels in the
graphics are lost in the resulting pdf.

As I said in my original post, this can be worked around by using dvips
-j0. The problem seems to be provoked by using a combination of the
latex "times" package and the "roman" pgplot font. Either omitting the
"times" package or changing to a different pgplot font avoids the problem.

Before we updated to Fedora 16 we were using the stock texlive-2007 in
Fedora 14 and we did not see this problem.

Roderick

[Norbert Preining]

Post by Roderick Johnstone
Before we updated to Fedora 16 we were using the stock texlive-2007 in
Fedora 14 and we did not see this problem.

Because AFAIR there the -j0 was the default ...
The problem is well known and not directly solvable without hacking
a lot of dvips.

So simply *edit* the config.ps file and change to use j0 always.


Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
ABERCRAVE (vb.)
To strongly desire to swing from the pole on the rear footplate of a
bus.
--- Douglas Adams, The Meaning of Liff

[Roderick Johnstone]

Post by Norbert Preining

Post by Roderick Johnstone
Before we updated to Fedora 16 we were using the stock texlive-2007 in
Fedora 14 and we did not see this problem.

Because AFAIR there the -j0 was the default ...
The problem is well known and not directly solvable without hacking
a lot of dvips.
So simply *edit* the config.ps file and change to use j0 always.

Thanks, thats what I've done.

I hadn't realized the default had changed.

Roderick

[Robin Fairbairns]

Post by Roderick Johnstone
I hadn't realized the default had changed.

remember that jindrich's stuff hasn't been "formally" released.

"j0" is an evil recognition of an evil effect of the old tex font
layouts. the world would a better place if it weren't necessary.
there's a reasonable argument to say that users should be "required" to
understand it, and to use it only when necessary -- this is, in effect,
what jindrich has done.

i would hesitate to do such a thing ... but then i'm only indirectly
involved in putting distributions together. (even though i've expunged
-j0 from my own processes.)

r

[Karl Berry]

Roderick,

It is not clear to me that -j0 is truly necessary. In principle, it
shouldn't be. If you send an actual example (.tex + .dvi + any .eps's)
that I can run, perhaps something could be done. Verbal descriptions
aren't enough to debug with.

Some changes have been made in the area of subsetting fonts in recent
times in dvips. Whether they are directly related to your case, I
cannot say without seeing the actual document.

Best,
Karl

[Karl Berry]

(Cc-ing for posterity. Roderick sent me the sample files off-list.)

If you look at main.ps you will see that the X-axis title of the
graph is missing superscript minus signs - also a letter g is
missing from the word "erg". Many of the tick mark labels on the
graph are also missing too.

Thanks for the example.

The problem I see is that pgplot.epsi says it uses no fonts:
%%DocumentFonts:
therefore dvips has no way of knowing what is going on. It is not a
PostScript interpreter. It just parses the %%DocumentFonts: line(s).

If I edit that line in pgplot.epsi to say:
%%DocumentFonts: Times-Roman
and then rerun dvips (+ ps2pdf), all the missing characters appear.

Looking at the dvips source, it is not immediately clear to me that what
it does necessarily suffices in all cases, but it does in this one, at
least for me.

If there is any way to report or fix the problem in whatever generated
pgplot.epsi (pgplot, I guess), that would be great. That is, the
failure to define any %%DocumentFonts. Failing that, I suppose -j0 is
the simplest approach. But it's not a bug that can be fixed in dvips ...

Best wishes,
Karl

[Roderick Johnstone]

Post by Karl Berry
(Cc-ing for posterity. Roderick sent me the sample files off-list.)
If you look at main.ps you will see that the X-axis title of the
graph is missing superscript minus signs - also a letter g is
missing from the word "erg". Many of the tick mark labels on the
graph are also missing too.
Thanks for the example.
therefore dvips has no way of knowing what is going on. It is not a
PostScript interpreter. It just parses the %%DocumentFonts: line(s).
%%DocumentFonts: Times-Roman
and then rerun dvips (+ ps2pdf), all the missing characters appear.
Looking at the dvips source, it is not immediately clear to me that what
it does necessarily suffices in all cases, but it does in this one, at
least for me.
If there is any way to report or fix the problem in whatever generated
pgplot.epsi (pgplot, I guess), that would be great. That is, the
failure to define any %%DocumentFonts. Failing that, I suppose -j0 is
the simplest approach. But it's not a bug that can be fixed in dvips ...
Best wishes,
Karl

Karl

Thanks for this analysis.

I'll certainly take the matter up with the guardians of pgplot.

Roderick