I'm trying to use Adobe Normalizer to convert PostScript files to PDF/A.
The problem I am having is that if a font isn't found it is a hard stop. I added the "--ignorestdttfonts=off" and that helps a little bit. Here's what I'm using for my command string:
demonorm -efi --ignorestdttfonts=off -r0 -P ICCProfiles\ -B ".\Settings\PDFA1b 2005 RGB.joboptions" +n -O -O c:\NormalizerOutput InputPsFile.ps
I am using /Times-Roman in my PostScript file, and I have times.ttf as an installed font, but I am getting this error:
%%[ Error: Times-Roman not found. Font cannot be embedded. ]%%
So I have 2 questions:
Given a TTF file, how do I know exactly what font name to use for
Adobe Normalizer?
How do I substitute a font when a font is not found? The default is
to use Courier, but that doesn't seem to be happening. I explicitly
added "--allowdefaultfont=on --defaultfont=Courier" but it had no
effect.
Adobe Normalizer will always look for the PostScript font name. Unfortunately unlike other Adobe products it will not create a fontlist (.lst) file where you can easily see the "FontName" and the location of the font file on your system. So you will have to find other ways to get the exact PostScript font name.
An easy way to see PostScript font names is to open the Distiller settings file (joboptions) using Distiller. You want to use Distiller because you want this to open in a GUI. On the left side panel select "Fonts" and under Embedding > Font Source > select C:\WINDOWS\Fonts\ (assuming the TTF file is installed here). The window below will list all the fonts in the C:\Windows\Fonts location. The fonts are listed by their PostScript font names. Note that PostScript font names do not appear with spaces. Look for the Times or Times Roman font that you have installed.
This does get quite tricky with Times or Times-Roman. Is your PostScript file (input file) referring to an Type1 or TrueType font?
In the Normalizer documentation (p174) the Times or Times New Roman family appears as:
Times
Times-Bold
Times-BoldItalic
Times-Italic
Times-Roman
Times New Roman
TimesNewRomanPS-BoldItalicMT
TimesNewRomanPS-BoldMT
TimesNewRomanPS-ItalicMT
TimesNewRomanPSMT
Note that Times and Times New Roman are not the same fonts. Times is a Type1 font and if you do not have this font installed on your system then Normalizer is correct in its error "Times-Roman not found. Font cannot be embedded."
Hope this information helps.
Adobe Normalizer, as I understand it (I don't have a copy) is essentially a server version of Acrobat Distiller. It accepts PostScript as an input and delivers PDF files.
So there are several possibilities:
1) Normalizer cannot use TrueType fonts installed on the server. From your description that doesn't seem to be the case, as you say that --ignorestdttfonts 'helps a little bit' (it might be useful to know what improves...)
2) Because the missing font is Times-Roman, its simply not embedding the font because it doesn't need to. The 'base 14' fonts are assumed to be included with any PDF consumer, and they don't need to be included. To be honest, this seems like the most likely, as I would have thought that Adobe would ship the base 14 fonts with the Normalizer.
3) The TrueType font isn't available to Normalizer. You haven't said how you installed times.ttf. Did you just install it on the OS (and what OS are you using anyway ?) or did you add it to Normalizer in some fashion ?
4) You may (as you think) have the font name incorrect. The problem is that you cannot use TrueType fonts directly in PostScript. In order to be used in a PostScript program they have to be converted into type 42 fonts. It may be that Normalizer simply can't do that. Do you have any reason to think it can ? If it can, then it may require a TrueType POST table, which is optional and may not be present in your font. However, the font name would be the same as the TrueType font name. The times.ttf I have is called "Times New Roman" and is in fact an OpenType font. If you want to use a font name with spaces you will have to make a string and convert to name :
(Times New Roman) cvn findfont
If you want to check the operation of the default font, I would suggest using a font name which is not one of the base 14, eg:
%!PS
/NoSuchFont findfont 20 scalefont setfont
10 10 moveto
(Hello World) show
showpage
Run that through Normalizer and see what comes out as the font. It may well be that it simply leaves the font request in place of course.
Finally; since this is a commercial product I assume you are entitled to support, wouldn't it be simpler just to ask Adobe ?
Related
I am not a programmer, but a normal user who uses Linux.
I want to use Ghostscript to DISPLAY Pdf files, not to CREATE Pdf files. (I have never used Ghostscript until now).
But I want Ghostscript to automatically replace all fonts with other fonts when I open the PDF. No matter if the fonts are embedded or not.
With which fonts should the fonts be replaced?
Answer: I want to create a list of fonts, that I want to be available for replacement.
But which of these fonts on the list should be used?
Answer: The one that best matches the metric of the font to be replaced.
Is it possible to do this somehow?
You can't get Ghostscript to do what you are asking. If a PDF file contains fonts Ghostscript will use those fonts, it will only substitute if it cannot find an embedded font.
The reason for this is simple; the font embedded in the PDF file is the correct font. It's Metrics are correct, and the mapping form character code to the appropriate glyph selector in the font will be correct.
It's also a non-trivial problem to select from a list of fonts the one which 'best matches the metrics of the font to be replaced'. What characteristics should be considered ? How should those be determined ?
When a font is not embedded then Ghostscript will consult its own list of fonts and CIDFonts. Both of these lists can be customised, the documentation is here
But since a substitute font is always going to be a compromise, you can't tell Ghostscript not to use the embedded fonts in a PDF. Well technically you could, by modifying the PDF interpreter, but you say you aren't a programmer, so I doubt you will want to try that.
I'm trying to convert some PDF files (generated with FastReports) to PCL, using Ghostscript, and it works nice, except that the words with accents show wrong characters.
This is how I call ghostscript:
bin\gswin32c -dBATCH -dNOPAUSE -sDEVICE=pxlmono -sFONTPATH=C:\Windows\Fonts -dDuplex -dFirstPage=1 -dLastPage=2 -sOutputFile=Parte.pcl -fParte.pdf
This is my original PDF:
This is the result PCL:
I guess the problem are the fonts, because it says it can't find the fonts Arial and Verdana (although both are installed on \Windows\Fonts).
GPL Ghostscript 9.27 (2019-04-04)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Processing pages 1 through 2.
Page 1
Can't find CID font "Verdana".
Attempting to substitute CID font /Adobe-Identity for /Verdana, see doc/Use.htm#CIDFontSubstitution.
The substitute CID font "Adobe-Identity" is not provided either. attempting to use fallback CIDFont.See doc/Use.htm#CIDFontSubstitution.
Loading a TT font from %rom%Resource/CIDFSubst/DroidSansFallback.ttf to emulate a CID font Adobe-Identity ... Done.
Can't find CID font "Verdana".
Attempting to substitute CID font /Adobe-Identity for /Verdana, see doc/Use.htm#CIDFontSubstitution.
Can't find CID font "Verdana".
Attempting to substitute CID font /Adobe-Identity for /Verdana, see doc/Use.htm#CIDFontSubstitution.
Can't find CID font "Arial".
Attempting to substitute CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution.
Can't find CID font "Arial".
Attempting to substitute CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution.
Page 2
Can't find CID font "Arial".
Attempting to substitute CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution.
Loading a TT font from %rom%Resource/CIDFSubst/DroidSansFallback.ttf to emulate a CID font Adobe-Identity ... Done.
Can't find CID font "Verdana".
Attempting to substitute CID font /Adobe-Identity for /Verdana, see doc/Use.htm#CIDFontSubstitution.
Is there any parameter to solve my problem with those fonts ?. Thank you.
PS: If you want to test the original PDF file, you can download it here : PDF File
Your PDF file uses the following CIDFonts; Arial, Arial,Bold, Verdana, Verdana,Bold and Verdana,BoldItalic. It does not include any of these fonts.
While it is poor practice not to include regular fonts, it is specifically stated in the specification that CIDFonts must be embedded. However, many creators fail to do so, presumably because it's comparatively hard. Much easier to include a reference and leave the hard work to the PDF consumer. So what if the font isn't available to the consumer....
If the font or CIDFont is not present Ghostscript must use a substitute. CIDFonts are harder to substitute for than regular Fonts, and Ghostscript ships with basically one real substitute CIDFont, DroidSansFallback, which it uses for all languages. There is a 'bullet' CIDFont which is the ultimate last-ditch fallback, as it contains nothing except a bullet glyph.
To get the correct output you must either embed the CIDFonts in the PDF file, or supply a suitable substitute CIDFont for Ghostscript to use. Note that the FONTPATH switch only applies to fonts, not CIDFonts, so it will not be useful for this file (though it may have benefits for files using fonts, obviously).
The CIDFont substitution mechanism is described in the Ghostscript documentation. I imagine that if you supply the various Windows TrueType fonts to Ghostscript as substitutes for the missing named CIDFonts then your file will render correctly.
Note that, since you are using Windows, Ghostscript will be using a ROM file system. If you edit the cidfmap file you will need to use the -I (Include) switch to add the path containing the cidfmap file to the search path. You may find it easier to simply edit the file in c:\Program Files (x86)\gs\gs9.27\Resource\Init and add that enter path using -I"c:/Program Files (x86)/gs/gs9.27/Resource/Init".
I am using Ghostscript v9.07 on Windows 7 (x64) to convert PostScript files into PDFs. Inside the PostScript files, the fonts Times-Roman and Times-Bold are used - this can be seen in the PostScript plain-text:
/Times-Roman findfont 24.00 scalefont setfont
.
.
.
/Times-Bold findfont 24.00 scalefont setfont
.
.
.
(This is extremely common in PostScript output from TeX.)
When I convert the PostScript to PDF using Ghostscript, Ghostscript uses the Nimbus-Roman font-family.
GPL Ghostscript 9.07 (2013-02-14)
Copyright (C) 2012 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusRomNo9L-Regu font from %rom%Resource/Font/NimbusRomNo9L-Regu... 39
38016 2393624 2695216 1387174 4 done.
Loading NimbusRomNo9L-Medi font from %rom%Resource/Font/NimbusRomNo9L-Medi... 39
38016 2453738 2695216 1390537 4 done.
This output suggests that it is loading the font-family from resources embedded in the executable. In any case, it isn't loading it from the PostScript file so it is either from the application's distribution or the operating system.
The result looks abysmal in every PDF viewer I have tried, regardless of font-smoothing settings.
I cannot understand it. The resulting PDF's text is not rasterised - you can select it and cut and paste it and the file-size alone shows that it is still real text - so I can only conclude that this is a quirk of the Nimbus-Roman typeface.
There is absolutely no reason to use that typeface but, no matter what I do, I cannot seem to get Ghostscript to use a Times-Roman (or equivalent) typeface from the Windows font set.
I tried the -sFONTPATH switch (alternatively called sFONTDIR on some sites - I tried both) to no avail and I went looking for the fontmap file to try hacking that but didn't find one for Windows - only fontmaps for other operating systems in the install directory.
How can I change this behaviour and stop Ghostscript from using the awful font?
The way to have Ghostscript use a specific font, rather than a substitute, is to embed the font in the input.
This:
/Times-Roman findfont 24.00 scalefont setfont
merely requests a font (and size), it does not include the font data. In the absence of the font, Ghostscript is forced to use a substitute font.
On Windows, Ghostscript uses the ROM file system, and does not ship with the support files. If you want to use those you can pull them from Git, and then use the -I switch. That will allow you to alter cidfmap which controls the CIDFonts known to Ghostscript, and fontmap.GS which controls the regular fonts known.
However, I don't see the result you do with the apparently bitmapped font. Perhaps you should try a newer version of Ghostscript. Or post an original PostScript program and converted PDF file so it would be possible to examine them.
[edit starts here]
OK so basically there's some problems with what you've put up above. The screenshot you have there is from page 1, but the 'font substitution', ie the loading of NimbusRoman-Regular and NimbusRoman-Bold (on current versions of Ghostscript) take place on page 5. Clearly the 'substitution' on page 5 can't affect what's on page 1. You would have seen that if you hadn't set -dBATCH, moral; when debugging a problem, keep the command line simple.
The actual 'problem' is that the PostScript program uses a type 3 bitmap font for all the text, the font being defined in the body of the program.
In short, the text is a crappy bitmap font because that's the way the PostScript has been created, it contains a crappy bitmap font and insists on using it (FWIW it appears to have been rendered at 300 dpi).
In fact the only text in the document which is scalable is the very text which uses Times-Roman (not a substitution, it uses the font from the interpreter instead of the bitmap font).
This is the text for the figure at the top of the page; 'point', 'p', 'X', 'line', 'Y', 'u', 'W'. This has been included as an EPS (originally called ray_space.eps) into the document, which is why it uses real scalable fonts. If you zoom in on the top of page 5 you will see that the scalable fonts continue to look smooth (the body of the figure) while the bitmapped font (the figure title for example) look bitmapped.
There's nothing you can do about that, essentially, other than recreate the PostScript from the original DVI document. This is not a bug (or at least, not a Ghostscript bug).
[and another edit...]
I'm afraid its not really simple.
There are 26 fonts named /Fa to /Fx, I am unsure why this is the case, since each font is capable of containing 255 glyphs yet most do not (at the same time, they don't just contain two glyphs either). There seems no good reason for the fonts being encoded as they are.
The program uses each font as it requires it, switching fonts when it needs different glyphs. Eg:
1 0 bop
392 319 a Fx (An)21 b(In)n(tro)r(duction)g(to)h(Pro)t(jectiv)n
(e)h(Geometry)670 410 y(\(for)f(computer)f(vision\))
815
561 y Fw(Stan)c(Birc)o(h\014eld)74 754 y Fv(1)67 b(In)n(tro)r(duction)
74 856 y Fu(W)l(e)
The 'Fx' and 'Fw' calls load the font dictionary which is then used by the following code. Frankly the Tex PostScript is difficult to figure out, one might almost think it was designed to be obfuscated.
Identifying which 2-byte pair beginning with 'F' require removing or replacing, and which do not (eg ASCII encoded image data) would be tricky. In addition the glyphs are rendered flipped in the y axis (to match the transformation matrix in use) so you would have to adjust the FontMatrix similarly for a substitute font.
If the fonts in these TeX font dictionaries always contained the same glyphs, it would be possible to define a set of substitute fonts (/Fa to /Fx) which could be used instead. These would need to be loaded into the TeXDict dictionary to replace the ones defined in the header of the progtam of course.
I'm not saying its impossible, but it would be a good amount of research effort to figure out what would be possible, and then a good amount of coding to implement it.
I have a PDF and need to edit its text.
It has an embedded font and I'm not able to find the font to install. Is it possible to edit the text and maintain its embedded font when I don't have the font installed?
I'm editing with Acrobat X and its warning me that I don't have the font and forcing me to change the font of the text I want to edit to one that I have installed. I've Googled for a couple hours and found the font family, but not the variation that's embedded. Because the font is already in the document, I would have thought Acrobat or another software program could tap it to allow me to edit, though I'm guessing I'm missing something.
It depends...
1.
Most likely, your embedded font is a subset of the full font. That means that it contains only these glyphs (shapes that represent printable characters) which were required as representations for characters used by the original PDF.
If your edit wants to insert a character that wasn't present in the original PDF, Acrobat (or any other editing method) has to use a different font. The font embedded in the PDF simply doesn't have glyph that is suitable for your edit!
Also, your subsetted font's name is not exactly like the full set font's name: it uses has a randomly composed 6 uppercase character prefix with a +-sign to build the used font name, like ABCXYZ+Arial.
You could employ the free (as in beer) Acrobat Plugin FontReporter to generate a list of all glyphs contained in your font.
You can also use this answer:
"How can I extract embedded fonts from a PDF as valid font files?"
to extract the font in question.
Then open the extracted font (which will be the subset variant, mind you!) in FontForgehttp://fontforge.github.io/en-US/), and there check two things:
the original font's license
the original font's creator
With that knowledge you could then definitely find the variant of the family that is embedded (or rather: that was present when the PDF generating and font embedding software created the subset).
2.
If the (subsetted) font you are looking at uses a so called "custom encoding", it may be almost impossible to edit the PDF file with standard tools (even if you have the same font locally installed that was used to create the PDF file).
I have a PDF which renders fine in Acrobat but fails to print during the PDF to PS conversion process on our printer's RIP. After uncompressing with pdftk and editing I've found if I replace the usage of a certain font it will print.
The font is a strange one, a TrueType subset with a single character (space).
If I pass the PDF through Ghostscript it reports no errors, however an Acrobat pre-flight check will report a missing glyph for space. This error is not reported for the original file. I'm just using a basic command: gswin32c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -o gs.pdf original_sample.pdf
I've pulled out the font data from the original PDF and saved it. Running TTFDUMP.exe produces an interesting result where it seems that the 'glyf' table is missing:
4. 'glyf' - chksm = 0x00000000, off = 0x00000979, len = 0
5. 'head' - chksm = 0xE463EA67, off = 0x00000979, len = 54
Just wondering, am I interpreting this result correctly? Is it valid to run TTFDUMP like this on extracted data from a PDF? I think a 'glyf' table is required based on the spec, at least for the first 4 necessary characters.
TTFDUMP run on the ghostscript PDF produces a similar result but with a 1-byte 'glyf' table.
If so it seems that Acrobat doesn't particularly care about the missing space while other programs (including the printer) do. It's odd it isn't reported as missing though until it runs through Ghostscript.
The PDF is created by Adobe InDesign and the font is copyrighted like most so I can't share it.
Edit - I've accepted Ken's answer as he helped me on the Ghostscript bug tracker. In summary, it seems the font is broken as suspected due to the missing glyf table. Until I hear otherwise I'll have to suppose this is a bug in InDesign, and will continue investigating.
Yes you can run ttfdump on an embedded subset font, its still a perfectly valid font.
A missing glyph is not specifically a problem, because the .notdef glyph is used instead, a missing .notdef means a font isn't legal.
I think you are mistaken about the legality of sharing the PDF file (from the point of view of font embedding). Practically every PDF file you see will contain copyright fonts, but these are permitted to be embedded and distributed as part of a PDF (or indeed PostScript) file. TrueType fonts contain flags which control the DRM of the font, and which can deny embedding in in PDF (or other formats). Ghostscript honours these embedding flags in the font as does Acrobat Distiller and other Adobe products.
There were some fonts which inadvertently shipped with DRM which prevented embedding, and there's a list somewhere of these, along with an explicit statement from the font foundry that its permissible to embed these fonts. I think this was somewhere on the Adobe web site a few years back.
So if you have a PDF file with the font embedded in it (especially if it was produced by an Adobe application) then I would be comfortable that its legal to share.
I'm having some trouble figuring out what the problem actually is, and how you are using Ghostscript. If you are running the PDF->PS and then back to PDF then all bets are off frankly. Round-tripping files will often provoke problems.
In any event I'm happy to look at the file but you will have to make it available.