This is all clearly defined in the PDF specs. Thus, Scribus normall does not embed Helvetica or any other base font if its not within the page box which defines the area to actually be printed. This is a normally sane choice as *by definition*, any PDF viewing application should have Helvetica or Arial along with the other 'base 14' fonts. I inspected this with PitStop Pro and found that indeed Helvetica is not embedded. I see the issue and in this case, the printer is being a bit too pedantic IMO. Are you seriously suggesting I should include Helvetica dummy text in a page in order to work around a bug in Scribus? I do not think using Helvetica in the page area only in order to have it included is an option - it's way too hackish. I Scribus won't allow me to send files that the printer accepts, I won't be using Scribus any more.
If I recall correctly, they use ApogeeX from Agfa. Their PDF preflight system would simply not accept my files unless I removed the page info. Note that the complaint originally came from the printer, not from me. the page info font should be embedded when all other fonts are embedded, and outlined when other fonts are outlined. I think that whatever font that is used for the Page information text should respect the font handling settings that are used for other fonts in the document, i.e. The font is used by Scribus to print the document name, folio and date. Helvetica only appears in Page info space added by Scribus to accomodate for the print marks.
0 kommentar(er)
