|
|
Thats an issue of the Cabaret viewer. The "/Helv" is an allowed abbrivation of the "/Helvetica" name, this was at least allowed up to PDF-1.5. And "/Helvetica" is one of the 14 base fonts that don't need to be embedded. |
|
|
From the PDF Reference (1.6), page 358: "In PDF, the term font refers to a font dictionary, a PDF object that identifies the font program and contains additional information about it. There are several different font types, identified by the Subtype entry of the font dictionary." Page 359: "Note: The font resource name presented to the Tf operator is arbitrary, as are the names for all kinds of resources. It bears no relationship to an actual font name, such as Helvetica" Page 368 (Tf operator): "font is the name of a font resource in the Font subdictionary of the current resource dictionary" Page 386: "Ordinarily, a font dictionary that refers to one of the standard fonts should omit the FirstChar, LastChar, Widths, and FontDescriptor entries." There's no indication that you are allowed to omit the whole font resource even if it would only look like << /Type /Font /Subtype /Type1 /BaseFont /Helvetica >> We will probably implement a workaround anyway, but I still think that the PDFs not valid. |
|
|
fschmid: regardless who's to blame for the issue, how hard would it be to implement a workaround for it in upcoming Scribus releases? |
|
|
Have changed now the code for the PDF forms that now the full name of the font is used. Should work now, any viewer application must support the 14 standard fonts. |
|
|
tested with 1.3.3.6cvs (after cbradney synced the anoncvs), still cannot open the PDF form in Cabaret -- uploading a screen shot with the error message and a new test form. eheck: could you tell us, what's missing now? |
|
2006-11-28 23:07
|
|
|
2006-11-28 23:08
|
cabaret_unexpected_exception.png (86,560 bytes) |
|
|
No idea what's wrong now, the PDF should be fine. |
|
|
That attached testform.pdf opens fine in Acrobat Reader. And its perfectly ok, i don't see anything wrong inside. |
|
|
Our code implements what I cited from page 368 of the PDF reference: the font given will be looked up in the corresponding resource dictionary (AcroForm's default resources in the case of fonts in default apperance). We support the standard fonts all right but they have to be declared as font resource as the spec says. Adobe Reader is much more tolerant of bad PDF (kind of like Internet Explorer is tolerant of bad HTML). We're trying to be too, but you just found a spot where we're strict. |
|
|
The fact you are stricly implementing the specs isn't bad. But be aware that lots of pdf creators take the Adobe Reader as reference. So you should try to behave similar. |
|
|
Another snippet from the PDF Reference(1.6), Page 16: • PDF prescribes a set of 14 standard fonts that can be used without prior definition. These include four faces each of three Latin text typefaces (Courier, Helvetica*, and Times*), as well as two symbolic fonts (Symbol and ITC Zapf Dingbats®). These fonts, or suitable substitute fonts with the same metrics, are required to be available in all PDF consumer applications. • A PDF file can refer by name to fonts that are not embedded in the PDF file. In this case, a PDF consumer can use those fonts if they are available in its environment. This approach suffers from the uncertainties noted above. • A PDF file contains a font descriptor for each font that it uses (other than the standard 14). The font descriptor includes font metrics and style information, enabling an application to select or synthesize a suitable substitute font if necessary. Although the glyphs’ shapes differ from those intended, their placement is accurate. |
|
|
Next snippet of the PDF Reference, this time from the new Reference for PDF-1.7. This one is very interesting: Note: Beginning with PDF 1.5, the special treatment given to the standard 14 fonts is deprecated. All fonts used in a PDF document should be represented using a omplete font descriptor. For backwards capability, viewer applications must still provide the special treatment identified for the standard 14 fonts. |
|
|
Ok. I'm talking about font *resources*, you're talking about font *descriptors*. I'm only saying that according to spec there should be a font *resource* for every font used. This font resource has to contain a font *descriptor* except for the standard fonts. I already said that we'll probably implement a workaround for the current issue. On the other hand what would a bug tracker be good for if one is not allowed to report what he/she thinks of as spec violations? |
|
|
> On the other hand what would a bug tracker be good for if one is not allowed to > report what he/she thinks of as spec violations? I don't want to offend anybody, i'm only trying to clear things up with the different things that are in the Reference. And i want that you are aware that not only Scribus might write incorrect PDF files. |
|
|
Oh, we are. You wouldn't think what strange PDFs are out there. Some things we find (and work around) before anyone else notices. Even Acrobat Professional creates PDF with out of range values. Unfortunately we didn't find this one. |
|
|
fschmid: fyi, the twin bug in the cabaret bug tracker has been assigned to ehk (==eheck, I suppose:) |
|
|
fschmid: fyi, the the twin bug in the cabaret bug tracker has been reported as resolved and backported (thx ehk) to the next maintenance release. I'll test it with our pdf forms and let you know about the results as soon as this maintenance release is made public. btw, a nice piece of news, good to know you guys care:) http://www.cabaret-solutions.com/de/sitenews#item05-Dec-2006-13-31-22 |
|
|
Fixed finally with fix for 0005385 |
- Anonymous
