[jira] [Comment Edited] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox

["Michael Klink (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304945#comment-14304945 ] 

Michael Klink edited comment on PDFBOX-2618 at 2/4/15 10:55 AM:
----------------------------------------------------------------

_(Due to some e-mail backlog, I became aware of this issue only pretty late, but as it was my remark on stackoverflow which made [~tilman] open this issue, I'll throw in my 2 cents anyway...)_

Admittedly, creating the complete solution, i.e. [~jahewson]'s option *A*, _Rebuild ICU4J and HarfBuzz ourselves_, is beyond the focus of PDFBox as is, and also beyond its capabilities considering current resources.

But is the other extreme (next to having nothing), i.e. option *C* _providing merely an example breaking some lines into a paragraph_, really desirable?

The major effect most likely will be that developers using PDFBox for creating documents will continue making their own layouting code (based upon the example or not), and that code will surely be worse than what could develop from an option *B* kind of approach.

It would not even be necessary to have such a layouter as part of the pdfbox core, it could even be a project in its own right as soon as there is a basic implementation, but it should be coupled tight enough to make clear that this is the recommended layouter PDFBox users should use and contribute to instead of re-inventing the wheel again and again.

(Admittedly it's easy for me to say all this because the PDF use cases I have to deal with usually don't involve genuine PDF creation and I, therefore, would not have to write or use the engine myself ;)...)

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?

Keeping APIs private to keep users from using them for their tasks IMO is a very bad idea in open source projects...


was (Author: mkl):
_(Due to some e-mail backlog, I became aware of this issue only pretty late, but as it was my remark on stackoverflow which made [~tilman] open this issue, I'll throw in my 2 cents anyway...)_

Admittedly, creating the complete solution, i.e. [~jahewson]'s option *A*, _Rebuild ICU4J and HarfBuzz ourselves_, is beyond the focus of PDFBox as is, and also beyond its capabilities considering current resources.

But is the other extreme (next to having nothing), i.e. option *C* _providing merely an example breaking some lines into a paragraph_, really desirable?

The major effect most likely will be that developers using PDFBox for creating documents will continue making their own layouting code (based upon the example or not), and that code will surely be worse than what could develop from an option *B* kind of approach.

It would not even be necessary to have such a layouter as part of the pdfbox core, it could even be a project in its own right as soon as there is a basic implementation, but it should be coupled tight enough to make clear that this is the recommended layouter PDFBox users should use and contribute to instead of re-inventing the wheel again and again.

(Admittedly it's easy for me to say all this because the PDF use cases I have to deal with usually don't involve genuine PDF creation and I, therefore, would not have to write or use the engine myself ;)...)

> 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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org