Export as PDF: temporary PS file?

[montython]

When exporting to PDF (built-in pdf export feature, not an extension), is there a way to access temporary postscript files?

If this involves editing the source code, what is the starting point?

[Phil]

Hi and welcome to the forum!

AFAIK, OpenOffice directly writes the PDF files (unlike PDF printer drivers that work via PostScript).
So there is no PostScript files produced, hence I also don't see any way of changing the source code to get them.

Why not using PostScript printer drivers from Adobe to create the PostScript files?

Regards,
phil

[montython]

Thank you Phil.

Yes, there are many alternative ways to produce postscript files. In fact, I am very satisfied with OpenOffice way of producing pdf files without the need for a printer driver installed. It is very clean and handy to use OpenOffice built-in export feature for this. As you know, OpenOffice embeds all fonts when creating pdf's and I agree that this is the standard way. As far as I can understand OpenOffice developers do not want to confuse users with advanced font embedding options.

The thing is, I wanted to check if I could have control over font embedding policy. If there exist temporary *.ps files and they are accessible, then it is possible to have advanced control on font embedding. (by using Ghostscript for example)

Why not use a printer driver : The reason is, you won't have pdfmarks (hyperlinks, bookmarks) in the pdf file. A solution could be using "extended pdf " extension together with a postscript printer driver and create postscript files including hyperlinks/bookmarks. But, OpenOffice built-in pdf export feature is very neat and practical and it would be excellent to have some optional control over font embedding. Maybe this could be possible via File >> Export as PDF >> Pdf Options (a new tab named "Fonts" for example), but I guess OpenOffice developers had intentionally avoided this. I was just looking for a workaround...





p.s.
Some extra info about OpenOffice created pdf's and Ghostscript for those who might be interested:

Some people might think why not use OpenOffice created pdf's directly as input for Ghostscript and play with advanced settings. If you try to change the embed status of any font with Ghostscript;

Code: Select all

gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -sOutputFile=output.pdf -c ".setpdfwrite << /NeverEmbed [/Verdana] >> setdistillerparams" -f oOo.pdf

(where oOo.pdf is a pdf created by OpenOffice export as pdf feature)

the resulting pdf will have corrupt Verdana font. Ghostscript encounters problems with the fonts embedded by OpenOffice. On the other hand, if you first convert the pdf to postscript and then resdistill to pdf, then you loose pdfmarks.

[Hagar Delest]

it would be excellent to have some optional control over font embedding. Maybe this could be possible via File >> Export as PDF >> Pdf Options (a new tab named "Fonts" for example), but I guess OpenOffice developers had intentionally avoided this.

But it has been requested, you should subscribe and vote for it (up to 2 votes per issue): Issue 21368 - PDF-Export: option for replacing fonts with acrobat base fonts.

[montython]

But it has been requested, you should subscribe and vote for it (up to 2 votes per issue): Issue 21368 - PDF-Export: option for replacing fonts with acrobat base fonts.

Thanks for pointing out.

Acrobat delivers 14 base Fonts with it products (
http://www.adobe.com/support/techdocs/1a7ce.htm )
(I think every PDF-viewer does so)
If there would be an option to replace fonts automaticly with one of those base
fonts (and then of course the font won't get embedded) you'll get _much_ smaller
pdf-files (Just like the font replacing that is in openoffice, but only for PDF)

This is what it says. The subject evolves into something different, but I have some comments on this:

Many pdf viewers including Adobe's current readers rely on system fonts to display the documents in case the fonts are not embedded inside the pdf. Adobe Acrobat Reader no longer has base-14 fonts included. For example, on a windows platform, if Adobe reader cannot access the truetype equivalents of base-14 Type 1 fonts, then it uses the last-resort fonts included in the installation. So, there is no need to replace any fonts.

The real question is "to embed or not to embed" in more general terms. And to decide which fonts to embed.

We know that the World does not revolve around Microsoft, Windows or Adobe. There are many people who use neither Windows nor Adobe Reader to view pdf documents. By definition, "portable document format" should be platform-independent. I guess anyone would agree that a true "portable document" should embed all the fonts used. So far so good. But, there are times when people might prefer not to embed some (or even all) fonts for various reasons.

As I have said before, probably OpenOffice.org developers intentionally kept it this way. If you include more and more advanced options, someone who doesn't know what she/he is doing will mess up with the font embed options and then come up with such an argument:

I create pdf's with OpenOffice, but my friends cannot view them properly. Don't use OpenOffice, it sucks.

I don't agree with the current policy, but I can fully understand it. More to that, it seems that this preference is not likely to change in the near future.

In my opinion, one-click pdf creation with default options should stand there, but the advanced settings should include options for different preferences including font embedding. For example, the following is a screen shot from the pdf creation options of another text processor.



An additional option such as "Don't embed base-14 equivalents" could be convenient. This as an whole would be a more general solution to what is indicated in Issue 21368 (which is open for 5 years).

[acknak]

OOo's built-in File > Print > Print to file creates PostScript output, which converts nicely to PDF, but I don't know if there is anything that will do that without embedding the fonts used.

I must say, I'm not sure I understand why this would be an attractive option. It seems to me that displaying a PDF with fonts other than what the document was designed for rather defeats the purpose of using PDF in the first place. Wouldn't it be preferable to design the document using only the standard fonts?

If you don't want embedded fonts, why not export to html, or RTF?

[Hagar Delest]

Sometimes, you produce PDF because it has to be non editable and readable for a long time period. But you don't need any specific nice looking font. I've produced plenty of such technical documents to be stored in a huge database just to keep history of design changes. And in that case, priority is the file size.

[acknak]

Ok, that's reasonable enough.

But what happens if you used a specific symbol from a specific font (i.e. a font with a special encoding), and now in your archived document, the symbol is displayed as missing, or worse, incorrect?

The priority for archival files is to have a safe and reliable record; efficiency seems secondary to me.

[Hagar Delest]

But what happens if you used a specific symbol from a specific font (i.e. a font with a special encoding), and now in your archived document, the symbol is displayed as missing, or worse, incorrect?

Same as PDFCreator (which I use in such cases ): if the font cannot be replaced by an Adobe one, embed it. So all the extra glyphs are embedded. But if I use Arial for example, PDFCreator will 'change' it to Helvetica.

[montython]

OOo's built-in File > Print > Print to file creates PostScript output, which converts nicely to PDF, but I don't know if there is anything that will do that without embedding the fonts used.

When using File > Print > Print to file, the software from which you are printing (OpenOffice in this case) turns over the job to the printer driver. A common postscript printer driver built into Windows is pscript5.dll (for nt5 systems) for example. The postscript file is produced by pscript5.dll, not by OpenOffice. The postscript will not have hyperlink, bookmarks information. And yes, distiller software like Adobe or Ghostscript can distill those ps files to pdf without embedding any fonts. (by fine-tuning embedding options for every font in general)

/EmbedAllFonts true/false, /NeverEmbed [/fontname1 /fontname2 ...], /AlwaysEmbed [/fontname1 /fontname2 ...] distiller options which are valid for both Acrobat Distiller and Ghostscript are for this purpose.


As I have said before, I agree with your arguments. A standard Portable Document Format file should embed all fonts for a platform-independent solution. But this is just a standard, not a must. Otherwise, there wouldn't be any options regarding font embedding policy in distiller software and pdf file specification. There are cases where selectively deciding which font to embed might be optimal. As in Hagar de l'Est example, if a person is creating pdf's for personal use only, and he/she knows that these pdf's will be viewed solely on MS Windows platforms, there is no point in embedding Windows system fonts. Not embedding these fonts will dramatically reduce file sizes and the display will be exactly the same assuming that you are on Windows. Another example is not to embed base-14 fonts. This will end up with 99.9 % portable documents (almost platform independent) which are significantly smaller in size.

Same as PDFCreator (which I use in such cases ): if the font cannot be replaced by an Adobe one, embed it. So all the extra glyphs are embedded. But if I use Arial for example, PDFCreator will 'change' it to Helvetica.

In fact this is what happens: PDFCreator uses pscriptN.dll and Ghostscript. Pscript printer driver has pre-defined font substitution tables and substitutes the fonts accordingly. You can check this from by right-click on printer, Device Settings > Font Substitution Table. It substitutes base-14 equivalents of truetype fonts with the Type 1 fonts. When the job is handed over to Ghostscript for distilling the ps to pdf, Ghostscript uses its default font embedding policy: Don't embed base-14 Type 1 fonts, embed anything else. For example you compose something in OpenOffice using Arial font and print it to PDFCreator. In the first step pscript5.dll substitutes truetype Arial with Type 1 Arial. In the second step, Ghostscript creates the pdf without embedding the Type 1 Arial font. If you change the font substitution table of postscript printer driver (psscript5.dll) not to substitute Truetype Arial with Type 1 Arial, Ghostcript will embed it. (it embeds all truetype fonts unless otherwise told with /NeverEmbed [/fontname] switch.

Things are similar for OpenOffice built-in pdf creation. It embeds all truetype fonts. The difference with Ghostscript is that there are no options to change the default font embedding policy in OpenOffice.

[acknak]

When using File > Print > Print to file, the software from which you are printing (OpenOffice in this case) turns over the job to the printer driver.

I don't believe this is the case for OOo. I'm sure that OOo on Linux uses its built-in PostScript output generator, and I strongly suspect that OOo on Windows does the same.