[
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
