[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=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=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
