André Wobst | 26 Jul 16:49 2011
Picon
Picon

Re: embedded fonts and dvips

Hi,

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 eventually.)

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:

andre <at> mbp:~/python/pyx/pyx/font$ svn diff
Index: font.py
===================================================================
--- font.py     (revision 3218)
+++ font.py     (working copy)
 <at>  <at>  -52,6 +52,8  <at>  <at> 
             if self.glyphnames:
                 file.write("%%Included glyphs: %s\n" % " ".join(self.glyphnames))
             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.t1file.getstrippedfont(self.glyphnames, self.charcodes).outputPS(file, writer)
         else:

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 anyway.

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):

andre <at> mbp:~/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
 <at>  <at>  -39,7 +39,8  <at>  <at> 
 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
 / <at> beginspecial{SDict begin/SpecialSave save N gsave normalscale
-currentpoint TR  <at> SpecialDefaults count/ocount X/dcount countdictstack N}
+currentpoint TR  <at> SpecialDefaults count/ocount X/dcount countdictstack N
+(*) {undefinefont} 128 string /Font resourceforall}
 N/ <at> 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  <at> beginspecial/ <at> 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) solution.

Best,

André

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
> <freynaxe <at> users.sourceforge.net> wrote:
>> Dear Gert, dear list,
>> 
>> On Fri, Jul 22, 2011 at 6:21 PM, Gert-Ludwig Ingold
>> <gert.ingold <at> physik.uni-augsburg.de> 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 include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> PyX-user mailing list
> PyX-user <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyx-user

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wobsta <at> users.sourceforge.net, http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

Attachment (smime.p7s): application/pkcs7-signature, 6319 bytes
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
PyX-user mailing list
PyX-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyx-user

Gmane