[reportlab-users] Another obscure error, this one regarding PDFPageLabel
Robin Becker
robin at reportlab.com
Wed May 20 05:49:35 EDT 2015
.......
>> It's fairly trivial to add
>>
>> def __lt__(self,oth):
>> return False
>>
>> to the PDFPageLabel class which makes all pagelabels with the same pagenumber
>> equal; that way the order in which they appear is fixed by the order of
>> addition (python sort is stable).
>
> Just fixing the message would be my preference, unless there is some rule that
> says multiple labels for one page must be permitted. I'd rather have spec
> adherence than my preferences :) Usually :)
Glenn,
I think the spec doesn't really care about duplicates
> PageLabels
> number tree
> (Optional; PDF 1.3) A number tree (see Section 3.8.6, “Number Trees”) defining the
> page labeling for the document. The keys in this tree are page indices; the
> corresponding values are page label dictionaries (see Section 8.3.1, “Page Labels”).
> Each page index denotes the first page in a labeling range to which the specified page
> label dictionary applies. The tree must include a value for page index 0.
Number trees don't seem to care about duplicates. They're only required to be in
ascending order which is why we did the sort.
So if you have them you need one for page 0, but otherwise all bets are off. If
the main content applies a labelling and then a subroutine for an appendix also
applies a labelling it's not at all clear that this is automatically an error.
I think after discussion with Andy we will go with the PageLabel.__lt__ ==>
False solution. That leaves detection of duplicates as a possible extension if
anyone wants to do it with their own PageLabels.
--
Robin Becker
More information about the reportlab-users
mailing list