[ https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305899#comment-14305899 ]
John Hewson commented on PDFBOX-2618: ------------------------------------- {quote} Keeping APIs private to keep users from using them for their tasks IMO is a very bad idea in open source projects... {quote} One of the biggest lessons which we've learnt is that this is wrong. In fact the opposite is true, the more implementation details which we expose publicly and the more classes which we don't mark as final, the more people abuse the internals of PDFBox with subclassing hacks and other tricks, rather than submitting trivial SVN patches to us on JIRA. We ended up with a situation in 1.8 where so many internal details were exposed that it became impossible to fix bugs without introducing breaking changes into the public API. Breaking changes make users unhappy but bugs made them more unhappy. Many users were annoyed that we could not fix the bugs without making breaking changes, but it was impossible due to the design. So for 2.0 we've learnt our lesson, we expose a low-level COS API for power users, and a high-level PD API for general usage, however the PD API does not expose its internals. We've restructured packages to make as many internals as possible package-private and final, so that we can fix bugs in the future without having to make breaking changes. What you're advocating is B) "Build half-baked fundamentally broken Western typesetting into PDFBox" and that's not something which I personally want to see become part of PDFBox, as it's not a typesetting library. PDFBox should stick to doing one thing well and not start taking on the responsibilities of other libraries. > Add an Example to create paragraphs with PDFBox > ----------------------------------------------- > > Key: PDFBOX-2618 > URL: https://issues.apache.org/jira/browse/PDFBOX-2618 > Project: PDFBox > Issue Type: Improvement > Components: Writing > Affects Versions: 2.0.0 > Reporter: Tilman Hausherr > > [~mkl] wrote this morning on stackoverflow on the topic about creating tables > with PDFBox: > {quote}I'm afraid all those samples IMO meely are proofs of concept, probably > of use in limited use cases but by far not for generic use. PDFBox has its > strengths, e.g. a quite versatile content extraction framework and a content > rendering capability, but the absence a proper layouting API is a serious > weakness.{quote} > To which I answered: > {quote}I know... I just don't want to create another iText. We're not the > Samwer brothers.{quote} > But he's right. We could of course look at what iText offers and implement > that on our own, that wouldn't even be illegal, but it wouldn't be nice. I've > never looked at or used iText, except once when answering this: > http://stackoverflow.com/a/26820598/535646 > IMO what we need to start, is a method to write a paragraph to a PDF. Such a > method would have these parameters: > - text > - rectangle (or width and height from current position) > Such a method would then output the text and break the lines at the end of > the rectangle, and throw an exception if the space isn't enough. > *UPDATE*: This will be implemented as an example, using either Java's > built-in TextLayout or ICU4J. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org