Features Download
From: =?iso-8859-1?Q?Andr=E9_Wobst?= <wobsta <at> users.sourceforge.net>
Subject: Re: embedded fonts and dvips
Newsgroups: gmane.comp.python.pyx.users
Date: Tuesday 26th July 2011 14:49:25 UTC (over 6 years ago)

well, in the end it is a quite simple problem. dvips does not remove the
UniqueID from the font when it subsamples a font. And depending on the font
it might not be reloaded from the input stream when it is already available
in the FontDictionary according to the UniqueID. So far so good. But what
can be done about it?

1. Prevent dvips from subsampling the fonts. Fine. Then you could even skip
the fonts in the figures completely if you use them in the output too. We
don't have an option in PyX to create such "broken" files even though this
should be quite trivial to implement. You could not view it without
embedding it, which is probably bad compared to having the font embedded in
the figure another time. (I badly remember the time I used metapost (more
then 10 years ago) where you always had to run the result through metapost
to get the fonts embedded; don't know whether this has been fixed

2. It is possible to denote the glyphs used in the figures so that dvips
can take care of including them in the documents' version of the subsampled
font (see http://www.radicaleye.com/dvipsman/dvips.html#SEC34).
A quick and dirty solution would be:

[email protected]:~/python/pyx/pyx/font$ svn diff
Index: font.py
--- font.py     (revision 3218)
+++ font.py     (working copy)
@@ -52,6 +52,8 @@
             if self.glyphnames:
                 file.write("%%Included glyphs: %s\n" % "
             if self.charcodes:
+                for charcode in self.charcodes:
+                    file.write("%%*Font: %s 1 1 %x:8\n" %
(self.t1file.name.lower(), charcode))
                 file.write("%%Included charcodes: %s\n" % "
".join([str(charcode) for charcode in self.charcodes]))
self.charcodes).outputPS(file, writer)

It fixes your example, but is rather incomplete. The %*Font-comments seem
to be requried to be placed close to the top of the file. Additionally the
tfm filename derived by self.t1file.name.lower() is just a crude hack. On
the other hand, the tfm filename is probably not the right name anyway, the
same font could be accessed by different tfm files. And the design size and
scaled size are not available at this position but should not be necessary

The correct solution to collect all the data would involve code in the dvi
directory, not just the font directory. In PyX we now have properly split
up those parts.

3. You can use dviconvert from the contrib directory to properly create do
the dvi->ps conversion. However, for that you need to install pyx.def and
graphicx.def and use \usepackage[pyx]{graphicx}. And please don't expect
PSTricks and other hacks to work in this "strict" mode. PyX does remove the
UniqueID from the subsampled fonts and thus no problem arises at all.

4. You could of course also just remove the UniqueID settings from the
postscript file created by dvips.

5. You can alter the dvips output to include a statement to empty the fonts
dictionary when including figures. Here is a simple patch to special.pro
(just create a local copy of it and patch it):

[email protected]:~/python/pyx$ diff -u
/usr/local/texlive/2011/texmf/dvips/base/special.pro special.pro 
+--- /usr/local/texlive/2011/texmf/dvips/base/special.pro       2006-01-03
00:51:56.000000000 +0100
+++ special.pro 2011-07-26 16:10:49.000000000 +0200
@@ -39,7 +39,8 @@
 newpath 4 copy 4 2 roll moveto 6 -1 roll S lineto S lineto S lineto
 closepath clip newpath moveto}N/endTexFig{end psf$SavedState restore}N
 /@beginspecial{SDict begin/SpecialSave save N gsave normalscale
-currentpoint TR @SpecialDefaults count/ocount X/dcount countdictstack N}
+currentpoint TR @SpecialDefaults count/ocount X/dcount countdictstack N
+(*) {undefinefont} 128 string /Font resourceforall}
 N/@setspecial{CLIP 1 eq{newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs
 neg 0 rlineto closepath clip}if ho vo TR hsc vsc scale ang rotate
 rwiSeen{rwi urx llx sub div rhiSeen{rhi ury lly sub div}{dup}ifelse

This will render all fonts unavailable from within the figure (within
@beginspecial/@endspecial) – even the builtin fonts will be unavailable.
An alternative to alter/unset the UniqueID for all fonts does not work. You
can't write into the font. At least as far as I tried namely by "findfont
/UniqueID undef" instead of "undefinefont".

To conclude this really is not a PyX bug at all. The best solution would be
if dvips would remove the UniqueID from the font when subsampling fonts.
However, I don't know whether there is still some active development on
this old tool to get it fixed upstream. Some other options are available as
well, but they may have some drawbacks. As this is really a dvips problem,
fixing it by disabling font stripping seems to be an appropriate (and save)



Am 22.07.2011 um 19:42 schrieb Axel Freyn:

> Partly the problem is known, eg Debian Bug #508528, tagged "wontfix"
> (However in my example, the necessary characters are included into the
> eps-files....)
> On Fri, Jul 22, 2011 at 7:34 PM, Axel Freyn
>  wrote:
>> Dear Gert, dear list,
>> On Fri, Jul 22, 2011 at 6:21 PM, Gert-Ludwig Ingold
>>  wrote:
>>>> I detected a VERY strange and frustrating behaviour of dvips together
>>>> with LaTeX and PyX... (Probably PyX is not guilty...)
>>>> When I
>>>>  - use PyX to generate eps-files containing some text
>>>>  - include those eps-files in a tex-file
>>>>  - convert the dvi-file to postscript
>>>> I loose some characters -- without any error messages or warning :(
>>> I can confirm this but I had no time to analyze the problem in detail.
>> I found at least an easy workaround:
>> "dvips -j0" works correctly. The j-option "downloads only needed
>> characters from Type 1 fonts", and is the default now.
>> Looking at the resulting .ps - files:
>>  - the .ps-file generated with "-j0" contains a full font encoding for
>> CMR10 at the beginning
>>  - the .ps-file generated without "-j0" contains only some characters
>> from CMR10 (probably "c")
>> However, BOTH files contain later the complete .eps-files as generated
>> by PyX, both also including their "own" embeded subsets of the font
>> CMR10.
>> I have no idea what would be the "correct" way according to
>> postscript, how such a situation should be handled?
>>  - rename the fonts and have 3 different fonts?
>>  - is it legal postscript to have 2 fonts with the same name, 1
>> "global" and then later redefine it in some sub-documents ?
>>  - combine the partial definitions to one "big" font?
>>  - something totally different?
>> Apparently, those later font-definitions are totally ignored by
>> ghostscript IF a font with the same name exists already in the
>> document?
>> Best regards,
>> Axel
> 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered
> Web security, SSL, hacker attacks & Denial of Service (DoS), private
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> PyX-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pyx-user

by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   [email protected], http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/
CD: 3ms