Am Freitag, 4. Juli 2014, 13:33:58 schrieb John Hewson:
> That’s certainly possible, I think part of the issue is that (speaking for
> myself) I’d rather see number and name trees handled more abstractly, the
> PD model should hide the details rather than exposing them all. Ideally we
> would end up with much less code.

I agree that it should normally not be required to use number and name trees 
directly. Though IMHO it's still not wrong to know which type of objects a 
container contains. Why should this information not be made available to 
someone who wants (for whatever reason) to access such a tree directly?
Anyhow it's nice to get response to at least one proposal after all...

Dominic

> -- John
> 
> On 4 Jul 2014, at 12:40, dnt <[email protected]> wrote:
> > I'm wondering if anyone had a closer look at it to think about an
> > integration into 2.0. It is meanwhile a bit older, but not necessarily
> > outdated. If you think the changes made sense I can create a patch that
> > can be applied to 2.0. The same holds true for my other proposals that I
> > submitted on the same day.
> > 
> > Dominic
> > 
> > Am Donnerstag, 3. Juli 2014, 01:27:25 schrieb John Hewson:
> >>     [
> >> 
> >> https://issues.apache.org/jira/browse/PDFBOX-1384?page=com.atlassian.jira
> >> .p
> >> lugin.system.issuetabpanels:all-tabpanel ]
> >> 
> >> John Hewson closed PDFBOX-1384.
> >> -------------------------------
> >> 
> >>    Resolution: Won't Fix
> >> 
> >> Closing due to the age of this patch.
> >> 
> >>> Proposals for a new PDNameTreeNode and PDNumberTreeNode
> >>> -------------------------------------------------------
> >>> 
> >>>                Key: PDFBOX-1384
> >>>                URL: https://issues.apache.org/jira/browse/PDFBOX-1384
> >>>            
> >>>            Project: PDFBox
> >>>         
> >>>         Issue Type: Improvement
> >>>         
> >>>           Reporter: Dominic Tubach
> >>>           Priority: Minor
> >>>           
> >>>            Fix For: 2.0.0
> >>>        
> >>>        Attachments: DTPDNameTreeNode.java, DTPDNameTreeNodeTest.java,
> >>>        DTPDNumberTreeNode.java, DTPDNumberTreeNodeTest.java>
> >>> 
> >>> Attached are proposals for a new PDNameTreeNode and a new
> >>> PDNumberTreeNode. (As both are very similar, I put them in one instead
> >>> of
> >>> two issues.) Main differences:
> >>> - type safety through generics.
> >>> - it's always clear which types of objects the array holds.
> >>> - flexible object conversion through COSBaseConverter.
> >>> - remove method.
> >>> - size and isEmpty method.
> >>> - correct updating of limits (even in parent nodes) when setting kids,
> >>> names or removing values. (Does not set limits in root node as defined
> >>> by
> >>> the PDF spec.) - removes empty child nodes.
> >>> Drawbacks:
> >>> - replacing the existing classes would require changes in existing code.
> >>> - requires (as of now) Java 1.6 (It might be enough to remove the
> >>> @Override annotations for Java 1.5 compatibility.) The required
> >>> COSBaseConverter can be found in issue #PDFBOX-1383
> >>> (To avoid conflicts with the existing classes i prefixed everything with
> >>> my initials.)
> >> 
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.2#6252)

Reply via email to