[jira] [Commented] (FOP-2431) Is there any possibility to convert PDF into XML using apache fop?
[ https://issues.apache.org/jira/browse/FOP-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227270#comment-14227270 ] Glenn Adams commented on FOP-2431: -- No. > Is there any possibility to convert PDF into XML using apache fop? > -- > > Key: FOP-2431 > URL: https://issues.apache.org/jira/browse/FOP-2431 > Project: Fop > Issue Type: Task >Reporter: swati dhingra > Labels: newbie > Original Estimate: 612h > Remaining Estimate: 612h > > We know Apache is used to convert XML Into PDF and so many other output > formats but is there any possibility that we can convert PDF into XML? > Any command? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2431) Is there any possibility to convert PDF into XML using apache fop?
[ https://issues.apache.org/jira/browse/FOP-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glenn Adams closed FOP-2431. > Is there any possibility to convert PDF into XML using apache fop? > -- > > Key: FOP-2431 > URL: https://issues.apache.org/jira/browse/FOP-2431 > Project: Fop > Issue Type: Task >Reporter: swati dhingra > Labels: newbie > Original Estimate: 612h > Remaining Estimate: 612h > > We know Apache is used to convert XML Into PDF and so many other output > formats but is there any possibility that we can convert PDF into XML? > Any command? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FOP-2431) Is there any possibility to convert PDF into XML using apache fop?
[ https://issues.apache.org/jira/browse/FOP-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glenn Adams resolved FOP-2431. -- Resolution: Invalid > Is there any possibility to convert PDF into XML using apache fop? > -- > > Key: FOP-2431 > URL: https://issues.apache.org/jira/browse/FOP-2431 > Project: Fop > Issue Type: Task >Reporter: swati dhingra > Labels: newbie > Original Estimate: 612h > Remaining Estimate: 612h > > We know Apache is used to convert XML Into PDF and so many other output > formats but is there any possibility that we can convert PDF into XML? > Any command? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2431) Is there any possibility to convert PDF into XML using apache fop?
swati dhingra created FOP-2431: -- Summary: Is there any possibility to convert PDF into XML using apache fop? Key: FOP-2431 URL: https://issues.apache.org/jira/browse/FOP-2431 Project: Fop Issue Type: Task Reporter: swati dhingra We know Apache is used to convert XML Into PDF and so many other output formats but is there any possibility that we can convert PDF into XML? Any command? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: svn commit: r1641827 - in /xmlgraphics/fop/trunk: ./ src/foschema/ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/autodetect/ src/java/org/apache/fop/fonts/type1/ src/java/org/apache
This is still not right. You need to revise the serialVersionUID on
EmbedFontInfo.java due to your making changes in the serialized fields.
Otherwise, end users (who aren't running junit) will still get clobbered
due to differences in the serialized cache and the new EmbedFontInfo
serialization.
On Wed, Nov 26, 2014 at 8:00 AM, wrote:
> Author: lbernardo
> Date: Wed Nov 26 15:00:57 2014
> New Revision: 1641827
>
> URL: http://svn.apache.org/r1641827
> Log:
> reapply r1637817 (new ant task removes cache)
>
> Added:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontUris.java
> (with props)
> Modified:
> xmlgraphics/fop/trunk/build.xml
> xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
>
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
>
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfigurator.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/EmbedFontInfo.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontLoader.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/LazyFont.java
>
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/FontInfoFinder.java
>
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/Type1FontLoader.java
>
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/java2d/ConfiguredFontCollection.java
>
> xmlgraphics/fop/trunk/test/java/org/apache/fop/fonts/DejaVuLGCSerifTestCase.java
>
> xmlgraphics/fop/trunk/test/java/org/apache/fop/fonts/EmbedFontInfoTestCase.java
>
> Modified: xmlgraphics/fop/trunk/build.xml
> URL:
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/build.xml?rev=1641827&r1=1641826&r2=1641827&view=diff
>
> ==
> --- xmlgraphics/fop/trunk/build.xml (original)
> +++ xmlgraphics/fop/trunk/build.xml Wed Nov 26 15:00:57 2014
> @@ -621,7 +621,7 @@ list of possible build targets.
>
>
>
> -
> +
>
>
>
> @@ -904,7 +904,7 @@ list of possible build targets.
>
> - + description="Runs all of FOP's JUnit tests"
> if="junit.present">
>property="fop.junit.failure"/> @@ -1525,6 +1525,9 @@ NOTE:
>
>
>
> +
> +
> +
>
>
>
>
> Modified: xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd
> URL:
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd?rev=1641827&r1=1641826&r2=1641827&view=diff
>
> ==
> --- xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd (original)
> +++ xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd Wed Nov 26
> 15:00:57 2014
> @@ -283,6 +283,8 @@
>
>
>
> +
> +
>
>
>
>
> Modified:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
> URL:
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java?rev=1641827&r1=1641826&r2=1641827&view=diff
>
> ==
> ---
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
> (original)
> +++
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfig.java
> Wed Nov 26 15:00:57 2014
> @@ -108,11 +108,13 @@ public final class DefaultFontConfig imp
> strict);
> continue;
> }
> -Font font = new Font(fontCfg.getAttribute("metrics-url",
> null), embed,
> -fontCfg.getAttribute("sub-font", null),
> fontCfg.getAttributeAsBoolean(
> -"kerning", true),
> fontCfg.getAttributeAsBoolean("advanced", true),
> -fontCfg.getAttribute("encoding-mode",
> EncodingMode.AUTO.getName()),
> -fontCfg.getAttribute("embedding-mode",
> EncodingMode.AUTO.getName()));
> +Font font = new Font(fontCfg.getAttribute("metrics-url",
> null), embed, fontCfg.getAttribute(
> +"embed-url-afm", null),
> fontCfg.getAttribute("embed-url-pfm", null),
> +fontCfg.getAttribute("sub-font", null),
> +fontCfg.getAttributeAsBoolean("kerning", true),
> fontCfg.getAttributeAsBoolean(
> +"advanced", true),
> fontCfg.getAttribute("encoding-mode",
> +EncodingMode.AUTO.getName()),
> fontCfg.getAttribute("embedding-mode",
> +EncodingMode.AUTO.getName()));
> instance.fonts.add(font);
> boolean hasTriplets = false;
> for (Configuration tripletCfg :
> fontCfg.getChildren("font-triplet")) {
> @@ -269,6 +271,10 @@ public final class DefaultFontConfig imp
>
> private final String embedUri;
>
> +private Str
Re: [VOTE] merge branches/Temp_BasicSideFloats to trunk
Looks like a great addition, Luis! +1 from me! Cheers! Clay -- "My religion is simple. My religion is kindness." - HH The Dalai Lama of Tibet > On Nov 25, 2014, at 3:05 PM, Luis Bernardo wrote: > > > Includes layout tests. > >> On 11/25/14, 5:14 PM, Glenn Adams wrote: >> What are your plans for testing? I haven't looked, but does your branch >> include new unit tests for this feature? >> >> On Tue, Nov 25, 2014 at 7:41 AM, Luis Bernardo >> wrote: >>> >>> I would like to merge the branch branches/Temp_BasicSideFloats to trunk. >>> The branch has a implementation of side floats that uses the same approach >>> used when handling change in IPD across pages. >>> >>> These are the known limitations: >>> -- the "clear" fo:float attribute is ignored; only the float attribute >>> (left or right) is used >>> -- overlapping of floats in the Y is not handled (even in the case there >>> would not be overlap in the X direction) >>> -- floats that extend beyond the body region are not properly handled and >>> will overflow past the edge of the region >>> -- if a float extends to bottom of the body region and there are footnotes >>> in the page the float may overlap with the footnote region >>> -- floats next to a table are not supported unless the start and end of the >>> table happens in between the start and end of the float >>> >>> Examples can be found in the thread with subject "RFC: basic side floats" >>> in this mailing list. >>> >>> To follow due process and since this will be a new major feature I am >>> launching a vote. >>> >>> Please vote or report a bug before the end of Monday UTC, December 1st. >>> >> >
Re: RFC: basic side floats
As a result of the work on lists and floats we can improve current support for lists when there is a change in IPD across pages. I have committed a small change to do that to this branch even though it is not really float related. An example is attached. On Tue, Nov 25, 2014 at 1:53 PM, Luis Bernardo wrote: > A new example that shows floats and footnotes in the same page. > > On Fri, Nov 14, 2014 at 9:34 AM, Luis Bernardo > wrote: > >> A more complex example that has a float inside a list. >> >> On Fri, Nov 7, 2014 at 4:41 PM, Luis Bernardo >> wrote: >> >>> A new example that involves a list that starts after a float starts (and >>> before it ends). >>> >>> On Mon, Oct 20, 2014 at 10:33 AM, Luis Bernardo >>> wrote: >>> FYI, I have created a new branch where I placed a new approach to side floats. The idea behind the approach is that if we can handle a change in IPD from one page to the next we can also do the same in the middle of a page (where a float causes the change in IPD). This also means that the implementation suffers, right now, from the same limitations that the handling of an IPD change across pages has. So, in summary: Left and right floats are supported in the most simple cases, including in multi-column layouts. Below are listed the known limitations: -- the "clear" fo:float attribute is ignored; only the float attribute (left or right) is used -- overlapping of floats in the Y is not handled (even in the case there would not be overlap in the X direction) -- floats that extend beyond the body region are not properly handled and will overflow past the edge of the region -- floats next to a table or a list are not supported unless the start and end of the table or list happen in between the start and end of the float -- a list can extend past the end of a float but only in situations where the list item at the end of the (bottom of the) float does not need to be wrapped; but wrapping before or after the bottom edge of the float is supported Attached is an example and the output (a similar two column example is in the layout tests). Comments, suggestion and bugs are welcome. I would like to commit this to trunk in a few weeks but meanwhile I will investigate alternative approaches to some of the current limitations. >>> >> > list-change-ipd-across-pages.pdf Description: Adobe PDF document http://www.w3.org/1999/XSL/Format";> (a) In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. (a) In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. (a) In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. (a) In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. (a) In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. (a) In olden times when wishing still helped one, there lived a king whose daughters were all beautiful, but the youngest was so beautiful that the sun itself, which has seen so much, was astonished whenever it shone in her face. (a) In olden times when wishing still helped one, there
Re: [VOTE] merge branches/Temp_BasicSideFloats to trunk
Hi Luis, great job! +1 2014-11-25 15:41 GMT+01:00 Luis Bernardo : > > I would like to merge the branch branches/Temp_BasicSideFloats to trunk. The > branch has a implementation of side floats that uses the same approach used > when handling change in IPD across pages. > > These are the known limitations: > -- the "clear" fo:float attribute is ignored; only the float attribute (left > or right) is used > -- overlapping of floats in the Y is not handled (even in the case there > would not be overlap in the X direction) > -- floats that extend beyond the body region are not properly handled and > will overflow past the edge of the region > -- if a float extends to bottom of the body region and there are footnotes > in the page the float may overlap with the footnote region > -- floats next to a table are not supported unless the start and end of the > table happens in between the start and end of the float > > Examples can be found in the thread with subject "RFC: basic side floats" in > this mailing list. > > To follow due process and since this will be a new major feature I am > launching a vote. > > Please vote or report a bug before the end of Monday UTC, December 1st. > -- pascal
