[
https://issues.apache.org/jira/browse/PDFBOX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923876#comment-13923876
]
John Hewson edited comment on PDFBOX-1963 at 3/7/14 1:32 PM:
-------------------------------------------------------------
{quote}
If the page number is kept for convenience, I think its better from a "user
convenience" point of view to have it start at one and not at zero. Whatever
the decision, it should be mentioned in the javadoc. Internal calls should
rather use the PDPage parameter to avoid this problem.
{quote}
Using zero-based indexes is the convention in Java, even for page numbers, for
example {{Pageable#getPageFormat(int pageIndex)}} from java.awt.print. It has
the benefit of keeping for-each loops simple by avoiding i = 1 and i <= size
which are non-idiomatic.
PDF supports page labels such as "i", "ii", "iii", 1, 2, 3, etc. which further
confuse this issue as page "1" in this case is 0-based page 3, or 1-based page
4, neither of which are convenient for the user.
The reason I removed PDPage from being the parameter here is that it is
possible to pass a PDPage from another document, which would would break the
contract of PDFRenderer. We could add a field to PDPage so that it keeps track
of its parent PDDocument and set the field in all of PDPage's constructors -
that way we could throw an exception if the PDPage argument does not come from
same document as PDFRenderer. Currently a page can be created independently of
a document, so that would change, which seems ok?
was (Author: jahewson):
{quote}
If the page number is kept for convenience, I think its better from a "user
convenience" point of view to have it start at one and not at zero. Whatever
the decision, it should be mentioned in the javadoc. Internal calls should
rather use the PDPage parameter to avoid this problem.
{quote}
Using zero-based indexes is the convention in Java, even for page numbers, for
example {{Pageable#getPageFormat(int pageIndex)}} from java.awt.print. It has
the benefit of keeping for-each loops simple by avoiding i = 1 and i <= size
which are non-idiomatic.
PDF supports page labels such as "i", "ii", "iii", 1, 2, 3, etc. which further
confuse this issue as page "1" in this case is 0-based page 3, or 1-based page
4, neither of which are convenient for the user.
The reason I removed PDPage from being the parameter here is that it is
possible to pass a PDPage from another document, which would would break the
contract of PDFRenderer. We could add a field to PDPage so that it keeps track
of its parent PDDocument and set the field in all of PDPage's constructors -
that way we could throw an exception if the PDPage argument does not come from
the document same document used by PDFRenderer. Currently a page can be created
independently of a document, so that would change, which seems ok?
> PDFImageWriter doesn't make use of PDFStreamEngine
> --------------------------------------------------
>
> Key: PDFBOX-1963
> URL: https://issues.apache.org/jira/browse/PDFBOX-1963
> Project: PDFBox
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Fix For: 2.0.0
>
>
> PDFImageWriter is a subclass of PDFStreamEngine, however it never uses any of
> its functionality, the writeImage methods could be marked as static and
> behave in the same manner.
> The relationship between PDFImageWriter, RenderUtil, and ImageIOUtil no
> longer matches its historical origins and needs to be refactored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
