Hi,
Am 17.09.2010 15:37, schrieb Timo Boehme:
Am 14.09.2010 20:41, schrieb Andreas Lehmkuehler:
Am 14.09.2010 09:41, schrieb Timo Boehme:
It might be the case that normally such names should be COSName objects
but most objects (color space objects etc.) allow the user to set such
names while creating/manipulating a PDF document and typically accept a
COSBase object. Thus the user might add the name as a COSString.
AFAIU the pdf specs, the "alternateColorspaces" array of a DeviceN
colorspace should only contain COSName objects. Do you have an example
with COSStrings instead of COSNames?
For the PDF documents I currently work with all use COSName objects. I
was more concerned that it could be set by a program using COSString
instead of COSName like you can see in
org.apache.pdfbox.pdmodel.PDDocumentCatalog line 124:
root.setItem( COSName.TYPE, new COSString( "Catalog" ) );
According to the specification "Catalog" should be of type COSName
(bug).
I fixed that with [1], thanks for the pointer.
Thus my aim is to have a robust program -
I agree with you, but we can't secure every getter to avoid NPEs otherwise the
code will mostly consist of if-not-null-clauses.
but maybe the intention
should be to signal such wrong type usage immediately to the user
instead of silently accept the value?
Yes, we should try to do so.
BR
Andreas Lehmkühler
[1] https://issues.apache.org/jira/browse/PDFBOX-839
