Nabble - FOP - Dev

New IF: Some thoughts...

2008-07-25T01:52:38Z

You've all noticed by now that I'm working intensively on the new IF.
Testing with documents only involving text and rectangles (i.e. what is
implemented right now), the new IF is almost twice as fast as the plain
area tree XML format. So I assume the goals for the new IF can probably
be met. It looks like the output format implementations really get
smaller, faster to implement and more readable. My only worry point is
handling advanced borders in a format-independent way. But it should all
be solvable.

I'm also building the SVG (1.1 and 1.2 Print WD) painter next to the
IFSerializer to see whether a subset of SVG might actually be used as
our new intermediate format. However, I don't see that SVG is the right
way because it would mean defining all sorts of extensions to handle all
the additional things needed for the IF. The SVG needs more hierarchy
(SVG g tags) for getting paint state right (verbosity). The stronger mix
of namespaces might make the thing slower, too. If course, we will also
mix namespaces in the new IF but only at defined points for FOP
extensions. Finally, there are currently no SVG Print implementation
that I know of. Because we need SVG Print's page and pageSet feature we
couldn't preview the file anyway with external tools. Firefow, Inkscape
and Batik won't display the SVG Print file.

Some additional thoughts while going forward...

I think I'd like to split the IFPainter interface in two. Our Renderer
interface is already much too big causing big subclasses with many
methods. If I put everything in the IFPainter interface something
similar will happen here, too. The obvious split-point IMO is the
page. The IFDocumentHandler would deal with setting up the document and
handling page-sequences. The IFPagePainter would deal with single pages.
Formats like PNG, Mars and XPS generate a new file per page inside their
ZIP containers. PDF, AFP and PostScript also have distinct objects for
pages. So I think that makes sense. Please chime in if you don't agree
or if you have better names for the interfaces.

You may have seen my recent addition to the Wiki page about resource
management. This is only an idea at the moment. Basically, it's about an
optimization for formats like PS and AFP (avoids a two-pass approach
when generating a resource-optimized print file).

Thoughts and opinions welcome.

Jeremias Maerki

DO NOT REPLY [Bug 45306] fo:instream-foreign-object in fo: marker does not work

2008-07-24T13:42:55Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45306

Andreas L. Delmelle <adelmelle@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED

--- Comment #3 from Andreas L. Delmelle <adelmelle@...> 2008-07-24 13:42:55 PST ---
(In reply to comment #1)

(Apologies for being so late with the reply)

> I'm wondering whether we really need to clone the whole foreign subtree, as we
> are quite sure (?) that it's not FO and it's self-contained ....

Yep, now that you mention it. :-)

Seems like it could also be solved by overriding
InstreamForeignObject.clone(FONode, boolean), to always pass 'false' for the
boolean parameter (= removeChildren)...?

I'll look into it again later, and see what would work best.

Thanks for the feedback.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45470] Better support for overriding default LayoutManagerMaker needed

2008-07-23T23:33:32Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45470

--- Comment #3 from Jeremias Maerki <jeremias@...> 2008-07-23 23:33:31 PST ---
(In reply to comment #2)
> What do you think about this solution? Do you know a better or simpler
> solution? The drawback of my solution is, you have to provide this extension
> for every possible XSL-FO processor.

Sorry, but I don't have a qualified opinion here as I know nothing of this XDP.
But it definitely sounds suboptimal if you have to hack a FO processor to make
this work.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45470] Better support for overriding default LayoutManagerMaker needed

2008-07-23T13:47:15Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45470

--- Comment #2 from Rainer Langbehn <langbehn@...> 2008-07-23 13:47:14 PST ---
(In reply to comment #1)
> Created an attachment (id=22308)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22308) [details]
> Proposed patch for the improvement
>
> Agreed, this is indeed not a good situation at the moment. I guess nobody
> really needed that feature. I prefer a protected setter. I'll attach a patch as
> proposal. If I don't hear any objections in the next 72 hours I'll commit the
> patch. Out of curiosity: what do you need to replace the block-container LM
> for?
>

Jeremias,
...you're really fast :-) Thanks for the patch.

FYI, I'm working on a collection of XSL Transformation stylesheets (XSLT) to
convert documents/forms from Adobe's XML Data Package (XDP) vocabulary into
documents in the W3C's XSL Formatting Objects (XSL-FO) vocabulary (eventually
with embedded XForms), http://xdp2fo.sourceforge.net. This project is still
in an early phase but the already produced outputs are very promising.

Some of the XDP container elements, which I map to absolute positioned block
containers, use the concept of an anchor point for positioned layout. The
location of the container's anchor point can be: topLeft, topCenter, topRight,
middleLeft, middleCenter, middleRight, bottomLeft, bottomCenter, bottomRight.
The given top and left coordinates are always related to the anchor point. In
my opinion there is no corresponding concept in XSL-FO. Therefore you have to
transform the left and top coordinates (writing mode is currently not
respected) in accordance to the anchor type given.

After some research my choosen solution looks like this:

1. During transformation embed the XDP anchorType attribute in the
corresponding block-container element (with XDP namespace).
2. Provide an extended BlockContainerLayoutManager that looks for this special
attribute during layout processing. If such an attribute is found, perform
the position adjustment after bpd and ipd are computed.
3. Remove the XDP attribute after processing.

What do you think about this solution? Do you know a better or simpler
solution? The drawback of my solution is, you have to provide this extension
for every possible XSL-FO processor.

BTW, for barcode processing I'm using Barcode4J. Thanks for all your great
work.

Bye Rainer

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45470] Better support for overriding default LayoutManagerMaker needed

2008-07-23T12:53:38Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45470

--- Comment #1 from Jeremias Maerki <jeremias@...> 2008-07-23 12:53:37 PST ---
Created an attachment (id=22308)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22308)
Proposed patch for the improvement

Agreed, this is indeed not a good situation at the moment. I guess nobody
really needed that feature. I prefer a protected setter. I'll attach a patch as
proposal. If I don't hear any objections in the next 72 hours I'll commit the
patch. Out of curiosity: what do you need to replace the block-container LM
for?

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45470] Better support for overriding default LayoutManagerMaker needed

2008-07-23T12:47:15Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45470

Rainer Langbehn <langbehn@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45470] New: Better support for overriding default LayoutManagerMaker needed

2008-07-23T12:38:55Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45470

Summary: Better support for overriding default LayoutManagerMaker
needed
Product: Fop
Version: 0.94
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: page-master/layout
AssignedTo: fop-dev@...
ReportedBy: langbehn@...

I have the requirement to replace the default BlockContainerLayoutManagerMaker
with my own implementation. After searching the code base I think the suggested
way is by using the setLayoutManagerMakerOverride(LayoutManagerMaker) method of
the FopFactory to override the default LayoutManagerMaker implementation.

My own LayoutManagerMaker is a subclass of the default LayoutManagerMapping.
Unfortunately, 'cause the map of LayoutManagerMakers is private and no
protected setter is given to change the default mapping set during
initialize(), one has to provide a second map of LayoutManagerMakers and
duplicate a lot of code to tell fop to use this new mapping.

My suggestion:
Either make the map of LayoutManagerMakers protected or preferably provide a
protected setter to change the default mapping.

Thanks in advance
Rainer

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45306] fo:instream-foreign-object in fo: marker does not work

2008-07-22T03:21:04Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45306

--- Comment #2 from Luca Furini <lfurini@...> 2008-07-22 03:21:04 PST ---
Created an attachment (id=22297)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22297)
"cheap" cloning of the foreign subtree

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45306] fo:instream-foreign-object in fo: marker does not work

2008-07-22T03:19:45Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45306

--- Comment #1 from Luca Furini <lfurini@...> 2008-07-22 03:19:45 PST ---
I'm wondering whether we really need to clone the whole foreign subtree, as we
are quite sure (?) that it's not FO and it's self-contained ....

I'm attaching a patch that clones the foreign tree root without deleting the
child pointers; I have performed a couple of tests and everything seems fine.
(actually, now I think of it, the patch is slightly sub-optimal, as we could
just clone the instream-foreign-object node and share the whole foreign
subtree)

If there are no remaining erroneous situations or objections I can apply the
patch to the trunk.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45454] New: Investigate the adoption of Apache Commons CLI

2008-07-22T03:18:53Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45454

Summary: Investigate the adoption of Apache Commons CLI
Product: Fop
Version: 1.0dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: general
AssignedTo: fop-dev@...
ReportedBy: vincent.hennebert@...

The o.a.f.cli.CommandLineOptions class is very ad-hoc. It may make sense to
switch to Apache Commons CLI to have both a more powerful and simpler parsing
of command-line options.
The problem is, the CLI 1.x branch is no longer maintained apart from bug
fixes, and the 2.x branch has not been officially released yet. Plus it might
not be worth the additional dependency.
To do: find the best way of solving this issue.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: svn commit: r678477 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontInfo.java

2008-07-21T23:33:06Z

Unless I'm totally mistaken that "synchronized" won't accomplish
anything as there's nothing in that method that is not thread-safe. I
wasn't able to reproduce the reported error but looking through FontInfo
I found that TRIPLETS_TYPE constant which looks fishy to me. The
Javadocs for toArray() says:

"a the array into which the elements of this list are to be stored, if
it is big enough; otherwise, a new array of the same runtime type is
allocated for this purpose."

If there's no matching triplet, the method will probably return the
constant's value (a FontTriplet[1]) and that single array item might
even be null. Furthermore, that array is reused and might have been
initialized with unwanted values in a prior call. I've attached a patch
that will fix fontLookup(). But I suspect that might not have been it,
yet.

On 21.07.2008 18:48:15 acumiskey wrote:

> Author: acumiskey
> Date: Mon Jul 21 09:48:14 2008
> New Revision: 678477
>
> URL: http://svn.apache.org/viewvc?rev=678477&view=rev
> Log:
> Renamed fname to more correct name fontKey.
> Made createFontKey() in FontInfo synchronized which should hopefully fix Ingo Maas's threading problem (http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200807.mbox/%3C000a01c8eb4b$42166e60$a701010a@ebp01422%3E).
>
> Modified:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontInfo.java
>
> Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontInfo.java
> URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontInfo.java?rev=678477&r1=678476&r2=678477&view=diff
> ==============================================================================
> --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontInfo.java (original)
> +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontInfo.java Mon Jul 21 09:48:14 2008
> @@ -319,10 +319,10 @@
> Integer size = new Integer(fontSize);
> Font font = (Font)sizes.get(size);
> if (font == null) {
> - String fname = getInternalFontKey(triplet);
> - useFont(fname);
> - FontMetrics metrics = getMetricsFor(fname);
> - font = new Font(fname, triplet, metrics, fontSize);
> + String fontKey = getInternalFontKey(triplet);
> + useFont(fontKey);
> + FontMetrics metrics = getMetricsFor(fontKey);
> + font = new Font(fontKey, triplet, metrics, fontSize);
> sizes.put(size, font);
> }
> return font;
> @@ -504,7 +504,7 @@
> * @param weight font weight
> * @return internal key
> */
> - public static FontTriplet createFontKey(String family, String style,
> + public static synchronized FontTriplet createFontKey(String family, String style,
> int weight) {
> return new FontTriplet(family, style, weight);
> }
>
>

Jeremias Maerki

FontInfo-MT.diff (4K) Download Attachment

Re: svn commit: r678394 - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp: ./ modca/

2008-07-21T23:01:08Z

Thanks, Adrian. It's also good to see that you're making progress with
image handling on the GOCA branch.

On 21.07.2008 17:21:54 Adrian Cumiskey wrote:

> Jeremias,
>
> Yes you are right, I'll look at amending this.
>
> Adrian.
>
> Jeremias Maerki wrote:
> > Adrian,
> >
> > what's the point in registering arbitrary image formats which are not
> > even directly supported by AFP and are converted to bitmaps or graphics
> > by the AFPRenderer? AFAICT, the modca package simply needs to know what
> > internally supported image type is used, not what image type the image
> > originally was. Also, what happens with formats like MathML, JBIG2, PNM and
> > whatever else might be used? Do they have to be registered to work
> > correctly? Doesn't seem right to me.
> >
> > On 21.07.2008 13:36:50 acumiskey wrote:
> >> Author: acumiskey
> >> Date: Mon Jul 21 04:36:49 2008
> >> New Revision: 678394
> >>
> >> URL: http://svn.apache.org/viewvc?rev=678394&view=rev
> >> Log:
> >> * Fixed bug in cache where object is not able to use IOB mechanism.
> >> * Added PNG unsupported (but now recognised) mimetype to MO:DCA Registry.
> >> * Added useful toString() to AbstractNamedDataObject.
> >>
> >> Modified:
> >> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/DataObjectCache.java
> >> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AFPDataStream.java
> >> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractNamedAFPObject.java
> >> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractPageObject.java
> >> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractPreparedObjectContainer.java
> >> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/Registry.java
> >> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/ResourceGroup.java
> > <snip/>
> >
> >
> >
> > Jeremias Maerki
> >
> >

Jeremias Maerki

Re: svn commit: r678394 - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp: ./ modca/

2008-07-21T08:21:54Z

Jeremias,

Yes you are right, I'll look at amending this.

Adrian.

Jeremias Maerki wrote:

> Adrian,
>
> what's the point in registering arbitrary image formats which are not
> even directly supported by AFP and are converted to bitmaps or graphics
> by the AFPRenderer? AFAICT, the modca package simply needs to know what
> internally supported image type is used, not what image type the image
> originally was. Also, what happens with formats like MathML, JBIG2, PNM and
> whatever else might be used? Do they have to be registered to work
> correctly? Doesn't seem right to me.
>
> On 21.07.2008 13:36:50 acumiskey wrote:
>> Author: acumiskey
>> Date: Mon Jul 21 04:36:49 2008
>> New Revision: 678394
>>
>> URL: http://svn.apache.org/viewvc?rev=678394&view=rev
>> Log:
>> * Fixed bug in cache where object is not able to use IOB mechanism.
>> * Added PNG unsupported (but now recognised) mimetype to MO:DCA Registry.
>> * Added useful toString() to AbstractNamedDataObject.
>>
>> Modified:
>> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/DataObjectCache.java
>> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AFPDataStream.java
>> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractNamedAFPObject.java
>> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractPageObject.java
>> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractPreparedObjectContainer.java
>> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/Registry.java
>> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/ResourceGroup.java
> <snip/>
>
>
>
> Jeremias Maerki
>
>

Re: svn commit: r678394 - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp: ./ modca/

2008-07-21T07:28:27Z

Adrian,

what's the point in registering arbitrary image formats which are not
even directly supported by AFP and are converted to bitmaps or graphics
by the AFPRenderer? AFAICT, the modca package simply needs to know what
internally supported image type is used, not what image type the image
originally was. Also, what happens with formats like MathML, JBIG2, PNM and
whatever else might be used? Do they have to be registered to work
correctly? Doesn't seem right to me.

On 21.07.2008 13:36:50 acumiskey wrote:

> Author: acumiskey
> Date: Mon Jul 21 04:36:49 2008
> New Revision: 678394
>
> URL: http://svn.apache.org/viewvc?rev=678394&view=rev
> Log:
> * Fixed bug in cache where object is not able to use IOB mechanism.
> * Added PNG unsupported (but now recognised) mimetype to MO:DCA Registry.
> * Added useful toString() to AbstractNamedDataObject.
>
> Modified:
> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/DataObjectCache.java
> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AFPDataStream.java
> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractNamedAFPObject.java
> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractPageObject.java
> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/AbstractPreparedObjectContainer.java
> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/Registry.java
> xmlgraphics/fop/branches/Temp_AFPGOCAResources/src/java/org/apache/fop/render/afp/modca/ResourceGroup.java

<snip/>

Jeremias Maerki

Bug report for Fop [2008/07/20]

2008-07-20T23:08:12Z

+---------------------------------------------------------------------------+
| Bugzilla Bug ID |
| +---------------------------------------------------------------------+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned |
| | OPN=Reopened VER=Verified (Skipped Closed/Resolved) |
| | +-----------------------------------------------------------------+
| | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial |
| | | +-------------------------------------------------------------+
| | | | Date Posted |
| | | | +--------------------------------------------------+
| | | | | Description |
| | | | | |
| 1063|New|Nor|2001-03-21|fop does not handle large fo files |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3824|New|Blk|2001-09-25|MIF option with tables |
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
| 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes |
| 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code |
|10379|New|Enh|2002-07-01|Improvement to FOP Classloader |
|12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses|
|12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to |
|13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br|
|13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string|
|14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples |
|14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu|
|14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat|
|14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver |
|14529|New|Nor|2002-11-13|SVG url references do not work |
|14679|New|Enh|2002-11-19|Pluggable renderers |
|14924|New|Nor|2002-11-28|Table disappears when it ends when the page ends |
|15020|New|Enh|2002-12-03|Reuse of fo-tree |
|16017|Opn|Nor|2003-01-13|Jpeg's and the PDF Serializer |
|16130|New|Nor|2003-01-15|PS-Renderer emits lots of redundant moveto's |
|16156|New|Nor|2003-01-16|0.20.5rc SVG example does not work |
|16713|New|Nor|2003-02-03|Hyphenation error in tables |
|17369|New|Nor|2003-02-25|Footnote duplication |
|17380|New|Nor|2003-02-25|Batik Component will not recognize feXXXX SVG elem|
|17921|New|Nor|2003-03-12|Kerning is broken for standard fonts |
|18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly |
|18801|New|Nor|2003-04-08|"visibility" property is not implemented |
|19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir|
|19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 |
|19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl|
|19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x|
|19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented |
|20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl|
|20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur|
|20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T|
|21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo|
|21905|New|Nor|2003-07-26|large list-item-label bleeds into following block |
|21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo|
|22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class |
|22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER & README (was [|
|24148|New|Nor|2003-10-27|Kerning upsets text-align="end" |
|24171|New|Nor|2003-10-28|[PATCH] 1st Attempt at Whole Site PDF |
|24378|New|Nor|2003-11-04|Minor problem in sample code for embedding |
|24663|New|Nor|2003-11-12|fo:block space-after property needs fixing |
|24804|New|Nor|2003-11-18|SVG Text to PS Output generates incorrect outlines|
|25022|New|Nor|2003-11-26|XSL-FO to PCL : images not included |
|25341|New|Nor|2003-12-08|percentage resolution not being recalculated on di|
|25411|New|Nor|2003-12-10|[WARNING] Error while constructing image from XML |
|25432|Ass|Maj|2003-12-11|Cannot embed the User Defined Characters into the |
|26047|New|Nor|2004-01-11|Space-after value remembered and used on second do|
|26590|New|Nor|2004-02-02|last character width in winansi font is missed |
|26848|New|Nor|2004-02-11|PNG images using JIMI instead JAI |
|27107|New|Maj|2004-02-20|TTF Reader fails |
|27727|New|Maj|2004-03-17|problem displaying Japanese fonts in PDF. |
|27890|New|Min|2004-03-24|fop.sh doesn't set exit status |
|29632|New|Maj|2004-06-17|Rendered reads fonts from disk everytime it render|
|29711|New|Maj|2004-06-21|[PATCH] LineArea.canBreakMidWord() RFC3066 fix |
|30006|New|Nor|2004-07-09|eps doesn't show up in recent GhostScript versions|
|30214|New|Nor|2004-07-20|PSGraphics2D.drawImage incorrect matrix generated |
|31039|New|Nor|2004-09-03|URL in basic-link is scrambled by encryption |
|31225|New|Nor|2004-09-14|Need embedded page sequence functionality |
|31301|New|Nor|2004-09-19|FOP limitation-Summary of columns value at Table F|
|31674|New|Enh|2004-10-12|Allow Print Renderer to select Printer and Tray. |
|31796|New|Cri|2004-10-20|Fop: Pdf generation dowsn`t work with j2sdk 1.5 |
|32054|New|Enh|2004-11-04|Pluggable area creation: AreaFactory |
|32100|Ass|Enh|2004-11-07|FOP "Starter Documents" |
|32107|New|Cri|2004-11-07|Move FOP wiki to secure |
|32201|Opn|Enh|2004-11-12|please, provide a manpage |
|32789|New|Cri|2004-12-21|Arabic words are broken for rendering PDF from FOP|
|32970|New|Cri|2005-01-06|Sticking words in generated PDF document |
|33174|New|Nor|2005-01-20|An unrecognized token'NaN' was found when opening |
|34355|New|Cri|2005-04-07|BufferOverflowException when running SVG2PDF on hu|
|35184|New|Trv|2005-06-02|Error while loading image http://xxx.xx.x/yyyy.tif|
|35500|New|Nor|2005-06-24|Missing .close() call on stream opened for JPEG im|
|35939|New|Nor|2005-07-30|[PATCH] Port of 0.20.5 Driver.java class |
|35948|New|Enh|2005-07-31|pre-patch for FOrayFont adaptation to Fop |
|36000|Ver|Maj|2005-08-03|PDF page margins larger, different than PS renderi|
|36011|New|Nor|2005-08-04|Setting word-spacing on justified blocks removes j|
|36238|Ass|Nor|2005-08-18|text-align="justify" doesn't work on custom fonts |
|36395|New|Nor|2005-08-27|Common Border and Background Properties not suppor|
|36408|Opn|Min|2005-08-29|FOP hyphenation splits consecutive digits onto sep|
|36533|Opn|Nor|2005-09-07|Incorrect ipd and twsadjust settings |
|36935|New|Blk|2005-10-05|table-layout="fixed" and width="auto", but auto-la|
|36977|New|Nor|2005-10-09|[PATCH]TextLayoutManager CJK line break |
|37108|New|Nor|2005-10-16|Patch for 0.20.5 to work with jdk1.5 |
|37114|New|Min|2005-10-17|No error message on illegal/unknown values on a pr|
|37116|New|Enh|2005-10-17|ESC POS Renderer |
|37136|Opn|Nor|2005-10-18|external-graphic dimensions and rendering |
|37236|Ass|Nor|2005-10-25|[PATCH] Fix gradients and patterns |
|37305|Ass|Nor|2005-10-30|Added deviceDPI to PDFDocumentGraphics2D |
|37505|New|Cri|2005-11-15|SEVERE FOP Exceptions should be thrown! |
|37579|Ass|Nor|2005-11-21|footnotes within tables and listsl get lost |
|38121|New|Nor|2006-01-04|border-separation disturbs table layout |
|38244|New|Nor|2006-01-12|table-column and number-columns-spanned (prepatch)|
|38264|Ass|Nor|2006-01-13|Hyphenation does not play well with preserved line|
|38639|Inf|Maj|2006-02-14|PDF not opening |
|38821|Opn|Nor|2006-03-01|The manifest file no longer has a Class-Path entry|
|38862|New|Maj|2006-03-06|No ImageReader for this type of image |
|38880|Ass|Nor|2006-03-07|Right border on fo:inline missing when hyphenate=t|
|39034|New|Nor|2006-03-20|page-number-citation : the text after overlaps the|
|39118|Ass|Nor|2006-03-27|[PATCH] Handling of page-number-citation-last |
|39184|New|Nor|2006-04-03|soft page break on new line |
|39215|New|Nor|2006-04-05|[PATCH] To render GIF external images in RTF outpu|
|39261|New|Min|2006-04-10|Rasterized paints upside down if coordinate system|
|39293|New|Enh|2006-04-13|FOP can't support bold,italic for chinese/other mu|
|39412|Ass|Nor|2006-04-26|wrong URL referred from FOP: Bugs and Other Tracka|
|39422|New|Nor|2006-04-27|[PATCH] Fop fails to render non-ascii characters i|
|39725|New|Maj|2006-06-05|page-position="last" and spans doesn't output all |
|39777|Ass|Enh|2006-06-11|[PATCH] GSoC: floats implementation |
|39840|Ass|Cri|2006-06-20|Multi page table fails with an endless loop error |
|39927|Ass|Nor|2006-06-28|Building FOP with GCJ |
|39968|New|Nor|2006-07-05|Absolutely positioned block-container affects the |
|40112|New|Nor|2006-07-26|keep-with-previous.within-page not working |
|40271|Ass|Nor|2006-08-17|[PATCH] auto table layout -- dirty draft |
|40288|Opn|Nor|2006-08-18|<base> url requires "/", failes otherwise |
|40464|New|Nor|2006-09-11|Improve handling of OpenType fonts |
|40465|New|Nor|2006-09-11|Obtain some OpenType fonts for testing |
|40468|New|Nor|2006-09-11|Use OpenType fonts from the STIX fonts project? |
|40529|New|Nor|2006-09-17|[PATCH] Possible bug in PSTextRenderer |
|40557|Ass|Nor|2006-09-20|PDF encryption and Acrobat 5 |
|40676|Ass|Enh|2006-10-04|png graphics are expanded/uncompressed in pdf caus|
|40699|New|Nor|2006-10-06|Invalid PDF for certain numerical values in SVG li|
|40798|New|Maj|2006-10-19|page-position="last" doesn't work for 1 page docum|
|40830|Inf|Nor|2006-10-27|Pb rendering SVG in fo:instream-foreign-object wit|
|41062|New|Nor|2006-11-28|Defect reading hyphenation patterns |
|41122|New|Nor|2006-12-07|[PATCH] flow-map 1.1 support |
|41149|Ass|Nor|2006-12-11|PNG causes NPE for RTF output |
|41251|Opn|Nor|2006-12-28|ArrayIndexOutOfBoundsException in multithreading e|
|41272|Opn|Nor|2006-12-31|Memory problem in 0.93 |
|41295|New|Min|2007-01-04|Examples cause fatals and excessive warnings |
|41300|New|Min|2007-01-05|FATAL error raised for proportional-column-width()|
|41306|New|Nor|2007-01-05|AWT claims to support out-of-order: doesn't |
|41377|Ver|Blk|2007-01-16|Alignment (end, right) does not work in table-cell|
|41379|New|Maj|2007-01-16|VerifyError on FopFactory.newInstance() using Tomc|
|41380|New|Min|2007-01-16|Content in tables affecting conditional spacing of|
|41389|New|Maj|2007-01-17|Rtf numbered lists without numbers |
|41440|Ass|Nor|2007-01-23|PDFSVGHandler causes missing resource bundle |
|41443|New|Nor|2007-01-23|[PATCH] FOP can't handle mixed-case hyphenation ex|
|41445|Inf|Nor|2007-01-23|no searchable text in pdf for <image xlink:href to|
|41633|New|Nor|2007-02-16|*-progression-dimension on inlines not implemented|
|41637|New|Nor|2007-02-16|in-line border-end does not always get rendered |
|41649|New|Cri|2007-02-16|fop0.93 - Does not generate svg line or svg rectab|
|41657|New|Nor|2007-02-19|No support for SVG 1.2 in instream-foreign-object |
|41667|New|Nor|2007-02-21|ImageProvider should be overridable in ImageFactor|
|41812|New|Trv|2007-03-11|fillRect writes wrong command |
|41822|New|Nor|2007-03-12|Generated example from \examples\fo\basic\list.fo |
|41894|New|Nor|2007-03-19|fo:block-container: percentage-lengths + width/hei|
|41918|New|Nor|2007-03-21|Thin Lines in AWTRenderer are not drawn |
|41942|New|Nor|2007-03-25|fo:leader elements are ignored when converted to R|
|41951|New|Nor|2007-03-26|External graphic doesnt size properly with height |
|41959|New|Nor|2007-03-27|External links are broken if pdf is encryped |
|41978|New|Maj|2007-03-28|Rogue entries on a blank page |
|41995|New|Enh|2007-03-30|[PATCH] Barcode Support for AFP Renderer |
|41999|New|Nor|2007-03-30|Unassigned code points cause ArrayIndexOutOfBounds|
|42028|New|Nor|2007-04-02|Incorrect rendering of GIF images |
|42034|New|Nor|2007-04-03|basic-link doesn't cover all text inside |
|42049|New|Nor|2007-04-04|RTF (and PDF) tables incorrectly handle margin-lef|
|42136|New|Nor|2007-04-16|PDFDocumentGraphics2D.translate() does not work co|
|42162|New|Nor|2007-04-18|hyphenation inside block in FOP works only for pur|
|42306|New|Nor|2007-05-01|[PATCH] AWT Viewer does not track page numbers in |
|42307|New|Cri|2007-05-01|[PATCH] Java2d renderers render arabic text incorr|
|42330|New|Nor|2007-05-03|Tibetan characters not rendered correctly in PDF |
|42352|New|Nor|2007-05-08|Problem with tiff gray render |
|42374|New|Nor|2007-05-09|List label and bodyindentation incorrect in RTF |
|42380|New|Nor|2007-05-10|FOP chokes on jar-embedded class path |
|42501|New|Nor|2007-05-23|basic-link not sizing correctly for external-graph|
|42577|Ass|Nor|2007-06-04|font-stretch [PATCH] |
|42600|New|Nor|2007-06-06|can not create page break in RTF |
|42601|New|Nor|2007-06-06|Image/text misalignment inside before-region table|
|42616|Opn|Nor|2007-06-08|fop bash script still broken under cygwin when cur|
|42617|New|Nor|2007-06-08|DOM tree cannot be built for a SVG graphic embedde|
|42685|Ass|Nor|2007-06-17|Printer restarts after sucessfull printing Postscr|
|42769|New|Nor|2007-06-28|Wrong border resolution in a table when there are |
|42779|Ass|Nor|2007-06-29|page-position and force-page-count with different |
|42808|New|Nor|2007-07-04|table footer overflows region-body area without wa|
|42845|Inf|Nor|2007-07-10|Printing error. Prints charater+1. |
|42861|Ass|Nor|2007-07-11|[PATCH] Font detection only works for first docume|
|42868|New|Nor|2007-07-12|font-weight on custom fonts |
|43166|New|Nor|2007-08-20|unclosed border on nested inlines |
|43226|Inf|Maj|2007-08-28|images in pdf are not displayed correctly with 0.9|
|43237|New|Nor|2007-08-29|IndexOutOfBoundsException |
|43357|New|Min|2007-09-11|PDFGraphics2D addImage method: image in PDF look a|
|43416|New|Nor|2007-09-18|content not rendered after a break-before="column"|
|43474|Ass|Nor|2007-09-25|wrap-option="wrap" doesn't work |
|43506|New|Nor|2007-09-28|NPE using a Tiff Image |
|43525|New|Nor|2007-10-01|"background-position" shorthand is not processed p|
|43570|New|Cri|2007-10-08|field ATTRIB_ROW_PADDING not found |
|43571|Ass|Maj|2007-10-08|Error resolving Font metric URL Jar |
|43651|New|Nor|2007-10-18|NPE without manually clearing image cache |
|43722|New|Nor|2007-10-29|arabic character isssue |
|43739|New|Nor|2007-10-30|PDF table of contents generated with incorrect pag|
|43808|New|Cri|2007-11-07|Apache FOP in a Servlet fails to work after upgrad|
|43844|New|Maj|2007-11-12|Extra blank lines added upon weird combinations of|
|43940|New|Min|2007-11-22|Faster method for double formatting |
|43962|New|Nor|2007-11-26|OutOfMemoryError while auto-detecting fonts |
|44023|New|Nor|2007-12-05|An empty fo:block artificially breaks a block-stac|
|44024|Ass|Nor|2007-12-05|About AFP renderer Issues when i try to using Aria|
|44160|Ass|Cri|2008-01-02|IndexOutOfBoundsException when creating pdf |
|44190|New|Cri|2008-01-09|<fo:block span="none"> : textblock is missing on l|
|44320|New|Nor|2008-01-29|Missing before/after border when break set on a ta|
|44324|New|Nor|2008-01-29|vertical-align or baseline-shift In table-cells ca|
|44328|New|Nor|2008-01-30|widows not respected when linefeed-treatment="pres|
|44358|New|Maj|2008-02-05|OufOfMem |
|44393|Opn|Nor|2008-02-11|Wrong fo.Constant values used for break class |
|44412|Inf|Nor|2008-02-13|Missing border-after when break-after set on a blo|
|44434|New|Cri|2008-02-15|FO java Memory Error |
|44452|New|Cri|2008-02-19|last upgrades don't render older fop xml files |
|44460|Ass|Enh|2008-02-21|[PATCH] PDF Embedded files implementation |
|44489|Ass|Enh|2008-02-26|AFP Renderer: Implement break-out mechanism to sup|
|44490|Ass|Nor|2008-02-26|AFP Renderer: Support for clipping is missing |
|44507|New|Nor|2008-02-29|PCL Renderer doesn't clip background images |
|44545|Inf|Nor|2008-03-06|Keep together do not work correctly on spanning ta|
|44616|New|Nor|2008-03-17|Merging algorithm for tables properly works only f|
|44634|Ass|Enh|2008-03-19|implement show-destination for fo:basic-link |
|44744|New|Nor|2008-04-03|PDFGraphics2D.drawString(AttributedCharacterIterat|
|44826|New|Nor|2008-04-15|last-page master reference interfered with span al|
|44885|Ass|Enh|2008-04-27|fo:inline-container implementation |
|44920|Ass|Nor|2008-05-02|nested, multi-page tables and keep-with-previous |
|45027|Inf|Nor|2008-05-18|Color 'blue' does not render correctly when 'fo:ex|
|45047|Ass|Nor|2008-05-20|Fixed row height not taken into account if the row|
|45070|Ass|Nor|2008-05-23|Spurious WARNING on span="inherit" |
|45079|Ass|Nor|2008-05-27|multi page table with marker |
|45097|Ass|Nor|2008-05-29|Questionable white-space-treatment behavior |
|45104|New|Nor|2008-05-30|Possible Thread Safety Problem in FOP 0.93 |
|45113|Ass|Enh|2008-06-01|[PATCH] Adding PDF Launch Action |
|45134|Ass|Nor|2008-06-05|FOP unwarranted page split on table with numbre-ro|
|45159|New|Nor|2008-06-07|fop buzzed on footnotes near page break |
|45171|Ver|Nor|2008-06-09|PNG files locked until JVM exits |
|45237|Ass|Nor|2008-06-19|Call order of FOEventHandler method is incorrect |
|45306|New|Nor|2008-06-29|fo:instream-foreign-object in fo:marker does not w|
|45307|New|Nor|2008-06-29|fo:block-container height issue |
|45342|New|Nor|2008-07-04|AFP Renderer does not properly handle AFP fonts wi|
|45351|Ass|Nor|2008-07-07|Unnecessary hyphenation, swallowed characters |
|45366|New|Enh|2008-07-08|Unable to create column break in RTF using FOP |
|45390|New|Nor|2008-07-13|PDF Extensions - Prototype |
+-----+---+---+----------+--------------------------------------------------+
| Total 245 bugs |
+---------------------------------------------------------------------------+

Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java

2008-07-20T11:39:09Z

On Jul 20, 2008, at 17:15, J.Pietschmann wrote:

> Andreas Delmelle wrote:
>> I understand... I still think it's a nice showcase for
>> character-by-character font-selection added by Max, so I'm
>> wondering, if
>> the AFPRenderer is the only exception, we should be looking at a
>> way to
>> fall back with a warning, rather than disabling the feature for all
>> other output formats as well (?)
>
> I think we could ask the renderer about available fonts. How should
> the
> API look like?

I haven't really thought this through yet, so I guess, from my
perspective, anything goes, as long as it would disable the feature
only for those renderers not supporting it.

If I'd have to implement it, I'd be looking at overriding
fo.properties.FontFamilyPropertyMaker.make(PropertyList), which has
access to the FOUserAgent, or the FopFactory's FontManager, and
should thus be able check for the availability of the fonts to find
out which ones can be used as initial values. That would be a more
than viable alternative for the hardcoded default in FOPropertyMapping.

But it's all still a bit vague...

Andreas

Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java

2008-07-20T08:15:13Z

Andreas Delmelle wrote:
> I understand... I still think it's a nice showcase for
> character-by-character font-selection added by Max, so I'm wondering, if
> the AFPRenderer is the only exception, we should be looking at a way to
> fall back with a warning, rather than disabling the feature for all
> other output formats as well (?)

I think we could ask the renderer about available fonts. How should the
API look like?

J.Pietschmann

DO NOT REPLY [Bug 45390] PDF Extensions - Prototype

2008-07-20T01:09:31Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45390

Andreas L. Delmelle <adelmelle@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #22261|0 |1
is obsolete| |

--- Comment #2 from Andreas L. Delmelle <adelmelle@...> 2008-07-20 01:09:29 PST ---
Created an attachment (id=22286)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22286)
updated prototype; some more experimenting...

The patch in attach disables processing of the extension in case PDF/A or PDF/X
conformance is active. Better safe than sorry. For users that really don't mind
the risk, we could still add a config option to override this.

On another note, adding a quick-and-dirty implementation for simple PDF strings
already allows adding some JavaScript as an OpenAction...

Most complete example I tested so far:

<pdf:dictionary type="catalog"
xmlns:pdf="http://xmlgraphics.apache.org/fop/extensions/pdf">
<pdf:name key="PageMode">FullScreen</pdf:name>
<pdf:dictionary type="normal" key="ViewerPreferences">
<pdf:boolean key="HideToolbar">true</pdf:boolean>
<pdf:boolean key="HideWindowUI">true</pdf:boolean>
<pdf:boolean key="FitWindow">true</pdf:boolean>
<pdf:boolean key="CenterWindow">true</pdf:boolean>
<pdf:name key="NonFullScreenPageMode">UseThumbs</pdf:name>
<pdf:name key="PrintScaling">None</pdf:name>
</pdf:dictionary>
<pdf:dictionary type="normal" key="OpenAction">
<pdf:name key="Type">Action</pdf:name>
<pdf:name key="S">JavaScript</pdf:name>
<pdf:string key="JS">this.print(false,0,this.numPages-1);</pdf:string>
</pdf:dictionary>
</pdf:dictionary>

The JavaScript was borrowed from Bugzilla #12610, which also attempted to
address this.

I'd say it's about time to look into adding some basic validation, shaving off
the rough edges (!!serialization!!), and adding some documentation and
testcases.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: PDF full screen mode...

2008-07-19T03:48:53Z

On Jul 18, 2008, at 19:24, Bill Harrelson wrote:

Hi Bill

> Thanks. Guess I just have to wait, and tell the users they have to
> check print scaling when they print.
>
> I tried patching a pdf file by hand to include the directive, and,
> as you predicted, got file corrupted errors (although that could be
> for a variety of reasons, so it's not conclusive.)

In theory PDF is editable by hand, but remember that it's still a
binary format, so it's /very/ sensitive to things like editors adding
linefeeds or screwing up the raw bytes due to implicit byte-to-char
conversion... You'd actually almost need a Hex editor to get it
completely right.

Anyway, I ran a test out of curiosity. It doesn't crash or give
corruption warnings on my end (Adobe Reader 8 for Mac), and checking
the document properties, the entry even seems to be correctly
recognized (meaning Reader does not rely on the PDF file version to
process the ViewerPreferences). Also, adding totally nonsensical
entries, which would generate PDF like '/Foo /Bar' (strictly speaking
not incorrect, just meaningless) did not have any damaging effects.

In the end, if it works, it works, I guess, so I'm not so sure
whether it's worth investing time into making things like that
impossible, BUT... if the user would specify something like
'<pdf:name key="Foo">[[Bar</pdf:name>', the file does get corrupted,
since the content is not a valid PDF name. Some degree of validation
is necessary to prevent this stuff from happening. The square
brackets should either be escaped (to '#5B'), or made illegal (i.e.
if necessary, the user should do the escapes himself). Maybe it would
make sense to have PDFName itself not allow invalid names to be
created. At any rate, additional logic for PDF parsing capabilities
seems to belong in the fop.pdf package, rather than on the side of
the extension.

Ultimately, it's also meant to reduce maintenance on our end. If the
PDF Reference evolves and allows new features, the extension should
make those available to the users with us having to add only a
minimal amount of code. None in case of the PrintScaling entry, since
there is already generic support for PDF names. Nice example of the
potential benefits, as opposed to the dangers described above.

I'm currently still planning to look into making a few modifications
to the format, and building in some safeguards (basic validation, if
you will). If you want to stay informed, add yourself to the CC-list
in Bugzilla #45390, and you'll be among the first to receive updates
on the status of the patch.

Cheers

Andreas

Re: PDF full screen mode...

2008-07-18T08:51:16Z

On Jul 17, 2008, at 20:08, Jeremias Maerki wrote:

> I've been quiet about about this PDF extension so far because I didn't
> see much harm in doing it in a generic way for some simple name/value
> pairs. If that goes much further (like doing hacks to produce some
> complex PDF structures but still forcing it into the generic
> extension)
> then I'm a bit concerned. I do prefer the non-generic form I
> proposed at
> the beginning on the Wiki. I don't think there will be any problems
> with
> PDF/A and PDF/X conformance but the further you go with a generic
> approach the less control you have if a generated file will be
> conformant. Please keep that in mind while working on this. Thanks.

OK, will do. As a plain and simple rule, I'd make it "either one or
the other". If the user specifies a conformance level, processing of
the extension is disabled, since otherwise FOP cannot guarantee the
conformance.

I see perfectly what you mean, and the idea of specifying PDF
'expressions' is way too dangerous to allow. That's why I'd like to
limit it to a handful of elements that, when combined, can serve to
compose simple dictionaries/entries. Obviously, the docs will have to
come with a Big Fat disclaimer that users are advised to stick to the
examples that we provide, unless they are absolutely certain they
know what they're doing...

In the meantime, I have received another reply from Bill, which
raises some more concerns (something that was already playing in the
back of my mind), namely, users that specify PDF 1.6 entries in a
document whose header indicates PDF 1.4. Not sure, but this is very
likely to cause unpredictable behavior in certain viewers... Some may
simply ignore the entry, others might consider the PDF to be corrupt/
invalid.

Bill, note that the entry in question may well be available in the
ViewerPreferences dictionary as of PDF 1.6, but FOP still produces
PDF 1.4 max.

Cheers

Andreas

DO NOT REPLY [Bug 45104] Possible Thread Safety Problem in FOP 0.93

2008-07-18T06:28:59Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45104

--- Comment #4 from Jeremias Maerki <jeremias@...> 2008-07-18 06:28:59 PST ---
Thanks for reporting that, but the problem is limited to 0.20.5. The code
indeed has multi-threading issues:
https://svn.apache.org/viewvc/xmlgraphics/fop/branches/fop-0_20_2-maintain/src/org/apache/fop/pdf/PDFCIDSystemInfo.java?view=markup

Current releases don't have that problem:
https://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/pdf/PDFCIDSystemInfo.java?view=markup

(In reply to comment #3)

> Hi,
>
> We are using FOP 0.20.5. We have recently started noticing that sometimes PDFs
> we generate are having problems with font embedding.
>
> Some times the CIDSystemInfo section gets written as follows:
>
> /CIDSystemInfo << /Registry (/CIDSystemInfo << /Registry (Adobe/CIDSystemInfo
> << /Registry (AdobeAdobe)/Ordering (UCS)/Ordering ()/Ordering
> (UCSUCS)/Supplement )/Supplement )/Supplement 000 >> >> >>
>
> where as it should be :
>
> /CIDSystemInfo << /Registry (Adobe)/Ordering (UCS)/Supplement 0 >>
>
> It clearly shows that there are threading issues. I am not sure if this issue
> also exists in latest version of FOP.
>
> Regards
> Anoop Sehdev

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45104] Possible Thread Safety Problem in FOP 0.93

2008-07-18T05:39:08Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45104

Anoop Sehdev <anoop.sehdev@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |anoop.sehdev@...

--- Comment #3 from Anoop Sehdev <anoop.sehdev@...> 2008-07-18 05:39:07 PST ---
Hi,

We are using FOP 0.20.5. We have recently started noticing that sometimes PDFs
we generate are having problems with font embedding.

Some times the CIDSystemInfo section gets written as follows:

/CIDSystemInfo << /Registry (/CIDSystemInfo << /Registry (Adobe/CIDSystemInfo
<< /Registry (AdobeAdobe)/Ordering (UCS)/Ordering ()/Ordering
(UCSUCS)/Supplement )/Supplement )/Supplement 000 >> >> >>

where as it should be :

/CIDSystemInfo << /Registry (Adobe)/Ordering (UCS)/Supplement 0 >>

It clearly shows that there are threading issues. I am not sure if this issue
also exists in latest version of FOP.

Regards
Anoop Sehdev

(In reply to comment #2)

> I kinda of assumed that there wouldn't be much help available. But I wanted to
> at least put this out there in case anybody might have seen something similar
> in the past, or in case someone else runs across it in the future.
> We have load tested this project many times, to no avail. Additionally, we
> identified a few different areas where the data mixup could potentially occur,
> but those were easily tested under heavy load with no negative results. It
> seems like there's some missing piece to the puzzle that we haven't been able
> to identify yet. The thinking here is that it might have something to do with
> how FOP handles things when running on WebSphere on a bogged-down mainframe.
> We have occasional CPU spikes, but the majority of these came when we had a
> configuration mixup that caused our CPU to run at 100% at peak times for a
> couple weeks. Outside of that time frame, we've only had a handful of
> occurrences out of around 230,000 hits. It's just too few to really get a
> handle on it. Besides, our company's direction for PDF generation has shifted
> away from FOP. I'm in the process of rewriting this last project now anyway.
> I was mostly posting this issue in case others had been experiencing anything
> similar or if there was just something glaring that you could point out to me.
> Thanks for your time. I truly appreciate your reply.
> Best regards--
> John Lulich

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

RE: Print JPEG HeadlessException - Please Help

2008-07-18T05:33:23Z

Just in case it means something, I ran into this problem when java.awt.headless was specified as "true" on the startup configuration for the OAS platform. Since we were running on a Windows PC we were successfully able to run Batik (and thereby FOP) by just changing java.awt.headless="false" (or removing all together). From my investigation at the time (albeit on FOP 0.20.5 and Batik 1.5beta4), the only way to successfully make it work was to run in a non-headless environment. In short, I did not find a way for FOP (and more specifically Batik) to work in a headless environment, regardless of what you set your properties to.

-----Original Message-----
From: Surj [mailto:underground121@...]
Sent: Friday, July 18, 2008 4:50 AM
To: fop-dev@...
Subject: Re: Print JPEG HeadlessException - Please Help

Looks like this is set for sure.

I even tried running with Java 1.5. I think I might be beyond help, time to
look for a new trade.

Andreas Delmelle-2 wrote:

>
>>----- Oorspronkelijk bericht -----
>>Van: Surj [mailto:underground121@...]
>>Verzonden: vrijdag, juni 13, 2008 09:23 PM
>>
>>Yes the 'java.awt.headless=true' specified as a parameter when starting up
>>the weblogic container, is there any other way of setting this i.e.
>>programmatically during startup.
>
> Can you also verify from within your code whether the setting was
> correctly processed?
>
> This you could check via:
>
> System.out.print("java.awt.headless=" +
> System.getProperty("java.awt.headless", "false"));
>
> In theory, you could use System.setProperty("java.awt.headless", "true")
> to set the value, but as is often the case with properties on the
> system-level, it could be that setting it programmatically has no effect
> at all.
>
>
> HTH!
>
> Cheers
>
> Andreas
>
>
>
>

--
View this message in context: http://www.nabble.com/Print-JPEG-HeadlessException---Please-Help-tp17821038p18525612.html
Sent from the FOP - Dev mailing list archive at Nabble.com.

----------------------------------------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.

Re: Print JPEG HeadlessException - Please Help

2008-07-18T02:49:30Z

Looks like this is set for sure.

I even tried running with Java 1.5. I think I might be beyond help, time to look for a new trade.

Andreas Delmelle-2 wrote:

>----- Oorspronkelijk bericht -----
>Van: Surj [mailto:underground121@yahoo.co.uk]
>Verzonden: vrijdag, juni 13, 2008 09:23 PM
>
>Yes the 'java.awt.headless=true' specified as a parameter when starting up
>the weblogic container, is there any other way of setting this i.e.
>programmatically during startup.

Can you also verify from within your code whether the setting was correctly processed?

This you could check via:

System.out.print("java.awt.headless=" + System.getProperty("java.awt.headless", "false"));

In theory, you could use System.setProperty("java.awt.headless", "true") to set the value, but as is often the case with properties on the system-level, it could be that setting it programmatically has no effect at all.

HTH!

Cheers

Andreas

Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java

2008-07-18T02:30:09Z

Hi Max,

The problem with AFP is that there is no concept of a default set of base fonts. You have to
purchase your fonts as a pack from IBM and I'm not too sure about the availability of Symbol and
Zapfdingbats - they seem have their own way of doing things :).

FOP does however provide a default base font configuration for AFP of sans-serif, serif and
monospace - but there are no guarantees as to their availability on any given installation. The
branch I am working (http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AFPGOCAResources)
also contains a populated fop.xconf which provides commonly used raster font configurations for
Times Roman, Helvetica and Courier.

Adrian.

Max Berger wrote:

> Adrian,
>
> for the same reason I must disagree with the this change: If the fonts
> are not available (symbol, zapf dingbats), fop will just fall back to
> the default font, where the character is also not available. What you
> loose in this case is a little bit of performance. What you gain is the
> chance that fop is finally able to produce special characters (which has
> been a missing feature for a long time). So rather than shorting this
> list, you could enlengthen it with the "symbol" fonts available in afp.
>
> Max
>
> Andreas Delmelle schrieb:
>> On Jul 17, 2008, at 19:39, acumiskey@... wrote:
>>
>> Hi Adrian,
>>
>>> Author: acumiskey
>>> Date: Thu Jul 17 10:39:14 2008
>>> New Revision: 677648
>>>
>>> URL: http://svn.apache.org/viewvc?rev=677648&view=rev
>>> Log:
>>> ZapfDingbats and Symbol is not always available on the AFPRenderer so
>>> we can't have these as default font family properties unfortunately.
>> I understand... I still think it's a nice showcase for
>> character-by-character font-selection added by Max, so I'm wondering, if
>> the AFPRenderer is the only exception, we should be looking at a way to
>> fall back with a warning, rather than disabling the feature for all
>> other output formats as well (?)
>>
>> Just my 2 cents.
>>
>> Andreas
>
>

Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java

2008-07-17T23:45:20Z

Adrian,

for the same reason I must disagree with the this change: If the fonts
are not available (symbol, zapf dingbats), fop will just fall back to
the default font, where the character is also not available. What you
loose in this case is a little bit of performance. What you gain is the
chance that fop is finally able to produce special characters (which has
been a missing feature for a long time). So rather than shorting this
list, you could enlengthen it with the "symbol" fonts available in afp.

Max

Andreas Delmelle schrieb:

> On Jul 17, 2008, at 19:39, acumiskey@... wrote:
>
> Hi Adrian,
>
>> Author: acumiskey
>> Date: Thu Jul 17 10:39:14 2008
>> New Revision: 677648
>>
>> URL: http://svn.apache.org/viewvc?rev=677648&view=rev
>> Log:
>> ZapfDingbats and Symbol is not always available on the AFPRenderer so
>> we can't have these as default font family properties unfortunately.
>
> I understand... I still think it's a nice showcase for
> character-by-character font-selection added by Max, so I'm wondering, if
> the AFPRenderer is the only exception, we should be looking at a way to
> fall back with a warning, rather than disabling the feature for all
> other output formats as well (?)
>
> Just my 2 cents.
>
> Andreas

signature.asc (268 bytes) Download Attachment

Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java

2008-07-17T11:13:06Z

Hi Andreas,

Just realised that this change broke some units tests... will look at fixing this.

Adrian.

Andreas Delmelle wrote:

Re: PDF full screen mode...

2008-07-17T11:08:26Z

I've been quiet about about this PDF extension so far because I didn't
see much harm in doing it in a generic way for some simple name/value
pairs. If that goes much further (like doing hacks to produce some
complex PDF structures but still forcing it into the generic extension)
then I'm a bit concerned. I do prefer the non-generic form I proposed at
the beginning on the Wiki. I don't think there will be any problems with
PDF/A and PDF/X conformance but the further you go with a generic
approach the less control you have if a generated file will be
conformant. Please keep that in mind while working on this. Thanks.

On 17.07.2008 19:18:32 Andreas Delmelle wrote:

> On Jul 17, 2008, at 18:53, Jeremias Maerki wrote:
>
> > For that you need an "Explicit Destination" (PDF 1.4, 8.2.1,
> > "[page /Fit]")
> > which you place as a value for the "OpenAction" key in the "Document
> > Catalog".
>
> Thanks for the pointer! Unfortunately for Bill, this means that the
> patch will need some more work to support (at least) PDF arrays as
> well, before the extension can be used for this purpose.
>
> I don't think adding arrays by itself would be too difficult. I was
> playing with the idea of using strictly typed objects (in favor of a
> type attribute on an abstract entry), which I'll probably add pretty
> soon. I'll see what I can do.
> The only potentially tricky part may be the indirect reference to the
> page object (?)
>
> IIC, this is a variable that the extension knows nothing about
> (should be set/provided by the renderer)
>
> Apologies for the false hope for an immediate solution, Bill. On the
> bright side, it's probably not too far away...
>
>
> Andreas

Jeremias Maerki

Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java

2008-07-17T10:50:38Z

On Jul 17, 2008, at 19:39, acumiskey@... wrote:

Hi Adrian,

> Author: acumiskey
> Date: Thu Jul 17 10:39:14 2008
> New Revision: 677648
>
> URL: http://svn.apache.org/viewvc?rev=677648&view=rev
> Log:
> ZapfDingbats and Symbol is not always available on the AFPRenderer
> so we can't have these as default font family properties
> unfortunately.

I understand... I still think it's a nice showcase for character-by-
character font-selection added by Max, so I'm wondering, if the
AFPRenderer is the only exception, we should be looking at a way to
fall back with a warning, rather than disabling the feature for all
other output formats as well (?)

Just my 2 cents.

Andreas

Re: PDF full screen mode...

2008-07-17T10:18:32Z

On Jul 17, 2008, at 18:53, Jeremias Maerki wrote:

> For that you need an "Explicit Destination" (PDF 1.4, 8.2.1,
> "[page /Fit]")
> which you place as a value for the "OpenAction" key in the "Document
> Catalog".

Thanks for the pointer! Unfortunately for Bill, this means that the
patch will need some more work to support (at least) PDF arrays as
well, before the extension can be used for this purpose.

I don't think adding arrays by itself would be too difficult. I was
playing with the idea of using strictly typed objects (in favor of a
type attribute on an abstract entry), which I'll probably add pretty
soon. I'll see what I can do.
The only potentially tricky part may be the indirect reference to the
page object (?)

IIC, this is a variable that the extension knows nothing about
(should be set/provided by the renderer)

Apologies for the false hope for an immediate solution, Bill. On the
bright side, it's probably not too far away...

Andreas

Re: PDF full screen mode...

2008-07-17T09:53:39Z

For that you need an "Explicit Destination" (PDF 1.4, 8.2.1, "[page /Fit]")
which you place as a value for the "OpenAction" key in the "Document
Catalog".

On 17.07.2008 18:31:13 Andreas Delmelle wrote:

>
> On Jul 17, 2008, at 15:07, Bill Harrelson wrote:
>
> Hi Bill
>
> > Thank you very much! (in advance).
> > I have a client that prints labels that we generate with fop to a
> > pdf file, but the default print settings are "Scale to fit", and
> > we're printing full bleed, so we need to set PrintScaling to 'None'
> > in the document.
>
> Before sending you the files and wasting your time, I'm checking also
> on fop-dev@, since I'm not sure whether this particular requirement
> can already be met by my patch. I've searched through the PDF
> Reference (1.5), and could not find any reference to an entry called
> 'PageScaling'. It's possible that this can be achieved by a
> combination of other entries, but to be honest, unless you already
> have a very good idea of what you want the patch for, I'm afraid it
> may prove to be too limited FTM... :/
>
> If there is no such entry/value in PDF, then specifying it might
> cause FOP to produce PDF on which the average PDF Viewer would choke.
>
>
>
> Cheers
>
> Andreas

Jeremias Maerki