[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304967#comment-14304967
]
Maruan Sahyoun commented on PDFBOX-2618:
----------------------------------------
{quote}
By the way, keeping a minimal implementation of such an API used for multiline
fields private is a sure way to have copies of different states of that private
API copied into projects using PDFBox making updates of PDFBox a hassle. Is
that desirable?
{quote}
It is because it's only targeted and tested against multiline text fields to
replicate Adobe Acrobats behavior. It shall not create the impression that it's
suitable for anything else. It's limited to overcome some of the current issues
in AcroForms and targeted for 2.0
A general composer for a single text block, not to speak about things such as
tables ..., needs to be more flexible, needs more capabilities and so on.
So the benefit of keeping it private is that - after PDFBox 2.0 and if we
decide to do so - we can add a layouting capability and reuse that from
AcroForms under the hood without breaking the API. We are simply not prepared
to add a layout feature to PDFBox 2.0. It already has so many new features and
changes and is being worked on for very long. Adding yet another big thing
would move the release out even more.
I think that after 2.0 is the time to look at that.
Finally I'm a strong supporter of such a capability but it's not a decision to
be made by a single person (nor am I able to implement such a thing).
> 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
