View Issue Details

IDProjectCategoryView StatusLast Update
0004620ScribusPDFpublic2007-02-24 23:12
Reportereheck Assigned Tofschmid  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformWin32OSWindowsOS VersionXP
Product Version1.3.3.4 
Fixed in Version1.3.3.8cvs 
Summary0004620: Undeclared font in default appearance (DA) of PDF
DescriptionThe DA entry in Annotations created for text fields uses an undeclared font. For a newly created text field the DA entry will contain "/Helv 12.00000 Tf 0.00000 0.00000 0.00000 rg" but "Helv" isn't declared anywhere in the PDF.
Steps To ReproducePlace a text field on a document and export as PDF.
Additional InformationThat's why Cabaret isn't able to open PDF forms from Scribus, see also also:

http://www.cabaret-solutions.com/phpBB2/viewtopic.php?p=138

http://www.cabaret-solutions.com/bugtracker/view.php?id=133
TagsNo tags attached.
Patch

Relationships

has duplicate 0004619 closed PDF forms: Cabaret cannot open Scribus PDF fonts due to an undeclared font in form fields 
related to 0005385 closedfschmid Bug creating the /DA attribute of PDF forms 
child of 0003831 acknowledged Metabug: PDF Forms 

Activities

fschmid

2006-11-28 13:54

administrator   ~0013596

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.

eheck

2006-11-28 14:14

reporter   ~0013597

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.

mhanski

2006-11-28 17:40

developer   ~0013602

fschmid: regardless who's to blame for the issue, how hard would it be to implement a workaround for it in upcoming Scribus releases?

fschmid

2006-11-28 22:08

administrator   ~0013607

Last edited: 2006-11-28 22:09

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.

mhanski

2006-11-28 23:06

developer   ~0013609

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

 

testform20061128.pdf (2,367 bytes)

2006-11-28 23:08

 

fschmid

2006-11-29 07:23

administrator   ~0013615

No idea what's wrong now, the PDF should be fine.

fschmid

2006-11-29 07:28

administrator   ~0013616

That attached testform.pdf opens fine in Acrobat Reader. And its perfectly ok, i don't see anything wrong inside.

eheck

2006-11-29 10:05

reporter   ~0013619

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.

fschmid

2006-11-29 10:12

administrator   ~0013621

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.

fschmid

2006-11-29 10:19

administrator   ~0013622

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.

fschmid

2006-11-29 10:35

administrator   ~0013623

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.

eheck

2006-11-29 10:51

reporter   ~0013624

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?

fschmid

2006-11-29 10:56

administrator   ~0013625

> 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.

eheck

2006-11-29 11:09

reporter   ~0013626

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.

mhanski

2006-11-30 20:03

developer   ~0013680

fschmid: fyi, the twin bug in the cabaret bug tracker has been assigned to ehk (==eheck, I suppose:)

mhanski

2006-12-13 12:17

developer   ~0013894

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

fschmid

2007-02-24 13:04

administrator   ~0015387

Fixed finally with fix for 0005385

Issue History

Date Modified Username Field Change
2006-11-28 13:08 eheck New Issue
2006-11-28 13:19 mhanski Relationship added has duplicate 0004619
2006-11-28 13:23 mhanski Additional Information Updated
2006-11-28 13:25 mhanski Relationship added child of 0003831
2006-11-28 13:54 fschmid Note Added: 0013596
2006-11-28 14:14 eheck Note Added: 0013597
2006-11-28 16:22 mhanski Additional Information Updated
2006-11-28 17:40 mhanski Note Added: 0013602
2006-11-28 22:08 fschmid Status new => resolved
2006-11-28 22:08 fschmid Fixed in Version => 1.3.3.6cvs
2006-11-28 22:08 fschmid Resolution open => fixed
2006-11-28 22:08 fschmid Assigned To => fschmid
2006-11-28 22:08 fschmid Note Added: 0013607
2006-11-28 22:09 fschmid Note Edited: 0013607
2006-11-28 23:06 mhanski Status resolved => feedback
2006-11-28 23:06 mhanski Resolution fixed => reopened
2006-11-28 23:06 mhanski Note Added: 0013609
2006-11-28 23:07 mhanski File Added: testform20061128.pdf
2006-11-28 23:08 mhanski File Added: cabaret_unexpected_exception.png
2006-11-29 07:23 fschmid Note Added: 0013615
2006-11-29 07:28 fschmid Note Added: 0013616
2006-11-29 10:05 eheck Note Added: 0013619
2006-11-29 10:12 fschmid Note Added: 0013621
2006-11-29 10:19 fschmid Note Added: 0013622
2006-11-29 10:35 fschmid Note Added: 0013623
2006-11-29 10:51 eheck Note Added: 0013624
2006-11-29 10:56 fschmid Note Added: 0013625
2006-11-29 11:09 eheck Note Added: 0013626
2006-11-30 20:03 mhanski Note Added: 0013680
2006-12-13 12:17 mhanski Note Added: 0013894
2007-02-24 08:44 mhanski Relationship added related to 0005385
2007-02-24 13:04 fschmid Status feedback => resolved
2007-02-24 13:04 fschmid Fixed in Version 1.3.3.6cvs => 1.3.3.8cvs
2007-02-24 13:04 fschmid Resolution reopened => fixed
2007-02-24 13:04 fschmid Note Added: 0015387
2007-02-24 23:11 plinnell Status resolved => closed