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@mbp:~/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" % " ".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@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 @@ -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) 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 > <[email protected]> wrote: >> Dear Gert, dear list, >> >> On Fri, Jul 22, 2011 at 6:21 PM, Gert-Ludwig Ingold >> <[email protected]> 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 > [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/
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-user
