[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438638#comment-16438638
]
Matthew Broadhead commented on PDFBOX-2618:
---
I am evaluating [http://dhorions.github.io/boxable/]. A table cell does not
have the ability to contain anything other than text or an image. It allows
html to be passed as a string in limited cases which is not a good idea. But
none of these libraries are more than proof of concept and it is not advisable
to build apps depending on these projects. I am surprised that you are
seriously recommending them. They all have disclaimers on their readme pages.
Also they are not projects under the Apache umbrella. So the question is what
is Apache recommending as the way forward for people who need a high level PDF
API? As FOP is now out of the picture due to XSLT no longer being supported in
Tomcat or TomEE.
> 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
>Priority: Major
>
> [~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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438634#comment-16438634
]
Maruan Sahyoun commented on PDFBOX-2618:
Hi,
there are already some projects. This is not a complete list though
- https://github.com/GlenKPeterson/PdfLayoutManager
- http://dhorions.github.io/boxable/
- https://github.com/vandeseer/easytable
As for the fop related issues - did you ask how the fop people are thinking
about these issues?
To replace fop there would be a lot to add to PDFBox-
- a layout model
- complex script support
- hypenation
.
> 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
>Priority: Major
>
> [~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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438621#comment-16438621
]
Matthew Broadhead commented on PDFBOX-2618:
---
I am trying to migrate from FOP to PDFBox because XSLT support is broken in
Tomcat and TomEE due to JSP taglibs
([https://bz.apache.org/bugzilla/show_bug.cgi?id=61875] and
https://bz.apache.org/bugzilla/show_bug.cgi?id=27717). This is due to Xalan
being broken https://issues.apache.org/jira/browse/XALANJ-2540. Xalan is now
abandoned and nobody is going to fix it. Therefore I am assuming that nobody
using Tomcat or TomEE should use FOP any more?
I agree that PDFBox should not have a high level API but a new project should
be started that depends on PDFBox that could at first offer some basic features
and slowly migrate everything from FOP. Could be called pdfbox-fop or
something. I think it needs to follow the structure of FOP because if a new
project starts without learning the lessons of FOP then it will almost
certainly run into trouble.
It could replicate all the structures as POJOs like fo:block etc.
> 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
>Priority: Major
>
> [~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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264389#comment-15264389
]
John Hewson commented on PDFBOX-2618:
-
Possible base implementations:
- [AWT
GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/Font.html#layoutGlyphVector(java.awt.font.FontRenderContext,%20char[],%20int,%20int,%20int)]
- [ICU4J rich
text|https://docs.oracle.com/javase/7/docs/api/java/awt/Font.html#layoutGlyphVector(java.awt.font.FontRenderContext,%20char[],%20int,%20int,%20int)]
- FOP?
> 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
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264101#comment-15264101
]
Maruan Sahyoun commented on PDFBOX-2618:
Now, as PDFBox 2.0 has been released, I'd like to revisit that discussion. With
PDF 2 coming along which deprecates things like {{NeedAppearances}} and
requires a form filling and annotation creating application to create the
necessary appearance streams we do need a basic typesetting/paragraph handling
capability which allows us to fulfill that need. We also do have to consider
being able to handle rich text as it's defined in the spec.
There is a very simple formatter to be able to handle ltr text formatting for
multiline fields which is very limited compared to the cases it needs to handle
if we want to fully support form filling and text annotations (so it was a good
decision to not make it public at the time).
Would anyone know of a base implementation we could use as a start to enhance
the current capabilities? If not I will be looking at enhancing the current
implementation.
> 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
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
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
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305034#comment-14305034
]
Maruan Sahyoun commented on PDFBOX-2618:
Understood. But if we make it public it's becoming part of the contract and we
can't change it. As a (potential) formatter will need a contract which we
haven't thought about in full we can't define such API yet and as a result it
has to be private.
As the API defines the contract there has to be a difference between public and
private and there is a use for private in open source projects even though the
code might be copied as is code available in public APIs which is still
lingering around and being reused although there are newer versions. Public
doesn't ensure that people are not using older versions of the code.
> 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
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304990#comment-14304990
]
Michael Klink commented on PDFBOX-2618:
---
I understand the reasons why one may want to make it a private API.
All I say is that there essentially isn't anything like a _private API_ in open
source projects. It will be copied or used via reflection. And that use will
show up on public forums. And programmers, especially less experienced ones,
will do the same without further consideration.
Those copies won't be updated when the original code is improved. Reflection
use reduces type-safety and introduces security issues in certain environments.
Thus, private APIs in open source libraries in essence lessen the average
quality of software produced with those libraries.
That's why I doubt that private APIs here are desirable.
> 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
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
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
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304947#comment-14304947
]
Maruan Sahyoun commented on PDFBOX-2618:
There are people supporting to have a (limited) layout capability in PDFBox and
there are people who are not because of all the potential issues arising from
that. We should also keep in mind that there is a small set of core developers
for PDFBox - so anything new needs to be considered under that perspective too.
I think you will see us revisiting that discussion after PDFBox 2.0 has been
released.
> 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
[jira] [Commented] (PDFBOX-2618) Add an Example to create paragraphs with PDFBox
[
https://issues.apache.org/jira/browse/PDFBOX-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304945#comment-14304945
]
Michael Klink commented on PDFBOX-2618:
---
_(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-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
