DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32970





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 17:44 ---
Thank you for quick reply.

Well, we have here a typical helpdesk problem - how to reproduce problem 
customer is reporting :-/. I know it, because I was on techsupport helpdesk one 
upon the time :-)

Disabling of kerning I did try early and it does not help at all.

Your reply discover that problem can be reproduced only on regional versions of 
Acrobat Reader. It does not matter, if it is Czech version or English Central 
European version. Of course I did not test all existing versions of AR, but I 
think that this example is satisfactionary.

To comment more versions you did test:
4.0.5 - we are not using it and so I did not test it
5.0.0 CE - regional czech version produces the error.
5.0.5 - english version - does not produce error, 
5.0.5 CE - regional czech version produces the error.
6.0.0 CE - English version for Central Europe produces the error
6.0.1 - English version does not produce the error
6.0.2 - as stated early, does not produce problem on regional czech version

So it seems, that problem is attached with  English CE or Czech CE versions of 
Acrobat of versions 5.x and 6.0.0 or 6.0.1.
But still here remains question, why PDF produced by XEP 4.1 does not produce 
the error on any version.

I am not expert - but only to give you any informations - can not be problem 
connected with embedding fonts some way? Maybe XEP uses a little bit different 
aproach for it?

To help you reproduce the problem I put on our ftp two examples of installation 
packages of AR 5.0.5 CE:

ftp.sybase.cz/pub

you can use anonymous login

Any conclusions, which can help us to solve this problem wellcomed


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

DO NOT REPLY [Bug 32992] New: - area contents overflows area in line

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32992

   Summary: area contents overflows area in line 
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


I noticed this strange behaviour of FOP (0.20.5): the more documents I 
generate, the less of these

  area contents overflows area in line

FOP messages appear! I tested it by generating the exact same document over and 
over. These messages decrease until they don't appear anymore at all! When I 
restart my application (JVM) the same behaviour occurs: first lots of thses 
messages ... decreasing ... vanishing at all. Of course "real" messages stating 
the text that cause the overflow 

area contents overflows area in line Hello, this-is-a-very-long-text-that-
doesnt-fit-into-the-FO-box

still occur (correctly).

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

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

[Jeremias Maerki]

On 07.01.2005 10:49:02 Finn Bock wrote:
> [Jeremias]
> 
> > would you please check if it is acceptable to put the inherited values
> > directly into the CommonMarginBlock? It might have been cleaner to
> > always get the value via the parent FO but I think in this case it helps
> > simplifying the code in TraitSetter and BlockLayoutManager.
> 
> It looks wrong, it feels wrong, but I'm not at all sure if it is wrong.

Same here. :-)

> But I would be tempted to drop the use of space-[start,end] traits and 
> instead let the renderers use [start,end]-indent traits and the 
> reference rectangle to calculate the start position of the content 
> rectangle.
>
> Alternatively calculate space-[start,end] based on the 
> [start,end]-indent traits on the parent area rather then the parent fo.

I'll see what I can do. I got a great environment to test now. ;-)
Thanks for your insight.

Jeremias Maerki

DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32970





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 12:56 ---
I checked on Acrobat Readers 4.0.5, 5.0, 6.0.2 and GhostScript 8.14 and all
showed your PDF and a newly generated one (using your sources) correctly, even
closing and reopening the file several times.

What you could try is to disable kerning by setting kerning="no" on each font,
but it may be necessary to remove all "kerning" elements from the font metrics
XML files. Maybe it has something to do with that but I'm not sure.

At the moment I have no clue what's wrong.

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

DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32970





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 12:27 ---
I am sending the font files, too. It is because I thing problem could be 
somewhere in embedding fonts or something similar. Our test did show two things:

1) If you remove font definitions for Arial from userconfig.xml, error never 
occurs... But # sign is displayed instead Czech characters, of course.
2) Very occasionaly Acrobat Reader shows error with text similar to "Can not 
remove 2ac2eArial font ." before GPF.

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

Re: Checking for OutputSource for renderer overrides

[Jeremias Maerki]

On 07.01.2005 11:01:28 Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > You're right, my change was suboptimal. When I think
> > about this I must
> > say that I'd prefer to remove that check entirely
> > and let the individual
> > renderers check if they have everything to write to
> > their target. 
> 
> I don't think so, because we need early checking at
> the command line and embedded usage to make sure all
> input is OK before proceeding.  That's a very common
> paradigm used in just every compiler or text
> processor.  FOP has been doing this for several years.

I think you're confusing things. Checking for the availability of an
OutputStream has absolutely nothing to do with the command line. Command
line parameter validation is the responsibility of the
CommandLineOptions class. If through the command line no OutputStream is
set it's a bug in FOP. If someone embeds FOP in his/her application the
not supplying an OutputStream when a renderer needs one is a bug and so
it doesn't matter if the error message comes early or only when the
renderer is started (Renderer.startRenderer()).

> > The
> > renderer knows best what it needs. 
> 
> I don't think so--all of the non-AWT based renderers,
> for the past seven years, require a OutputSource and
> only an OutputSource.  We never had a user complaint
> on that or a request otherwise for a change.  It has
> never been a problem.

You mean OutputStream, not OutputSource, don't you?

> BTW, you are glossing over how one can generate a PDF
> or any other output document without using an
> OutputSource.  Absent user demand or a technical
> explanation from you on this point, I can't really
> support your position.

Ok, here's your technical justification:
I'm certain you've seen the new test subsystem for the layout engine
where I analyze the output of the area tree renderer. If I wrote the
area tree to an OutputStream I'd have to parse it again later, so I get
a DOM I can evaluate XPath statements on. If I can pass in a
TransformerHandler into the XMLRenderer the renderer can simply send SAX
events which are used by a Transformer to build a DOM from (directly).

Ok, this is no end-user use case but it's still a use case. You could
even argue that speed is no big issue in this case. Granted.

So here's another one. Do you know about SVG Print? An SVG renderer
could send the generated SVG using SAX. That way a developer could run
the generated SVG through an XSLT post-processing without having to
reparse the generated SVG. That's a place where speed is very important
and an OutputStream-only system would be suboptimal.

> > Having this check
> > in the
> > RendererFactory only puts renderer-dependant logic
> > in a place that is
> > renderer-agnostic. If it's ok by you I'm going to
> > fix that.
> > 
> 
> Personally, I would rather we get rid of
> RendererFactory and put the logic back where it
> was--in FOTreeBuilder and RenderPagesModel.  This
> functionality is just too specific to be reused
> elsewhere in FOP.

I don't see your point and you were the only one who complained about
the RendererFactory. I still think the RendererFactory is A Good Thing 
(tm). It reduces imports, dependencies and number of lines in
FOTreeBuilder and RenderPagesModel and centralizes instantiation of the
Renderers and FOEventHandler in one place where they are easier to find
for those unfamiliar with FOP sources.

I'll gladly submit to a veto against the RendererFactory if it is
supported by at least another committer.

> > I see two possibilities: Adding a RENDER_CUSTOM
> > constant or having a Fop
> > contructor without this constant.
> > 
> 
> RENDER_CUSTOM is OK.  (But there can also be
> advantages of still encouraging users to use
> RENDER_PDF, for example, if the override is still a
> PDF renderer.  e.g., checking for an output source or
> other business logic.)

Ok.

> > Please keep in mind that if you simply define a new
> > API, release and
> > then change according to user feedback you can't
> > just change the API in
> > an incompatible way again. You'd have to provide
> > API-compatibility
> > within smaller version steppings. See for example
> > [1].
> > 
> 
> Indeed, this reason is why I'm against adding API
> methods without an explanation of the technical needs
> for them, or bothering to point to user demand or
> requests for them first.  Once it's there, we're
> forever stuck with it unless we do another major
> release.  So I think you should be keeping versioning
> etc. in mind as well.
> 
> This is also the reason why we are using a simple
> JAXP-based API--something we know that we will support
> now and forever.  (Adding to an API is always OK, as
> more functionality and enhancements are provided--it
> is *subtracting* from it that causes the problem.) 
> Additional functionality should be based on user
> requests and needs, not every possible theoretical
> usage.



Jeremias Maerki

DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32970





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 12:22 ---
Created an attachment (id=13926)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13926&action=view)
font files used in example - part 2


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

DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32970





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 12:21 ---
Created an attachment (id=13925)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13925&action=view)
font files used in example - part 1


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

DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32970





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 12:20 ---
Created an attachment (id=13924)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13924&action=view)
Example of error. Please read readme.txt

Thanks for response. Sorry that example is in Czech. I hope you will see the
correct display of text from attachet image or text source in xsl. If it will
make big problem, I can try to prepare example with english text section.
Error can be seen in the middle of fifth page of pdf example.

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

Re: Checking for OutputSource for renderer overrides

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> You're right, my change was suboptimal. When I think
> about this I must
> say that I'd prefer to remove that check entirely
> and let the individual
> renderers check if they have everything to write to
> their target. 

I don't think so, because we need early checking at
the command line and embedded usage to make sure all
input is OK before proceeding.  That's a very common
paradigm used in just every compiler or text
processor.  FOP has been doing this for several years.

> The
> renderer knows best what it needs. 

I don't think so--all of the non-AWT based renderers,
for the past seven years, require a OutputSource and
only an OutputSource.  We never had a user complaint
on that or a request otherwise for a change.  It has
never been a problem.

BTW, you are glossing over how one can generate a PDF
or any other output document without using an
OutputSource.  Absent user demand or a technical
explanation from you on this point, I can't really
support your position.


> Having this check
> in the
> RendererFactory only puts renderer-dependant logic
> in a place that is
> renderer-agnostic. If it's ok by you I'm going to
> fix that.
> 

Personally, I would rather we get rid of
RendererFactory and put the logic back where it
was--in FOTreeBuilder and RenderPagesModel.  This
functionality is just too specific to be reused
elsewhere in FOP.


> I see two possibilities: Adding a RENDER_CUSTOM
> constant or having a Fop
> contructor without this constant.
> 

RENDER_CUSTOM is OK.  (But there can also be
advantages of still encouraging users to use
RENDER_PDF, for example, if the override is still a
PDF renderer.  e.g., checking for an output source or
other business logic.)

> Please keep in mind that if you simply define a new
> API, release and
> then change according to user feedback you can't
> just change the API in
> an incompatible way again. You'd have to provide
> API-compatibility
> within smaller version steppings. See for example
> [1].
> 

Indeed, this reason is why I'm against adding API
methods without an explanation of the technical needs
for them, or bothering to point to user demand or
requests for them first.  Once it's there, we're
forever stuck with it unless we do another major
release.  So I think you should be keeping versioning
etc. in mind as well.

This is also the reason why we are using a simple
JAXP-based API--something we know that we will support
now and forever.  (Adding to an API is always OK, as
more functionality and enhancements are provided--it
is *subtracting* from it that causes the problem.) 
Additional functionality should be based on user
requests and needs, not every possible theoretical
usage.

Thanks,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

[Finn Bock]

[Jeremias]
would you please check if it is acceptable to put the inherited values
directly into the CommonMarginBlock? It might have been cleaner to
always get the value via the parent FO but I think in this case it helps
simplifying the code in TraitSetter and BlockLayoutManager.
It looks wrong, it feels wrong, but I'm not at all sure if it is wrong.
But I would be tempted to drop the use of space-[start,end] traits and 
instead let the renderers use [start,end]-indent traits and the 
reference rectangle to calculate the start position of the content 
rectangle.

Alternatively calculate space-[start,end] based on the 
[start,end]-indent traits on the parent area rather then the parent fo.

regards,
finn

DO NOT REPLY [Bug 32970] - Sticking words in generated PDF document

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32970





--- Additional Comments From [EMAIL PROTECTED]  2005-01-07 10:28 ---
Please attach a testcase (FO file) so we can reproduce such a PDF ourselves.
Otherwise, I don't know how to help.

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

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

[Jeremias Maerki]

Finn or Simon,

would you please check if it is acceptable to put the inherited values
directly into the CommonMarginBlock? It might have been cleaner to
always get the value via the parent FO but I think in this case it helps
simplifying the code in TraitSetter and BlockLayoutManager.

On 07.01.2005 09:21:21 jeremias wrote:
> jeremias2005/01/07 00:21:21
> 
>   Modified:src/java/org/apache/fop/fo/properties CommonMarginBlock.java
>src/java/org/apache/fop/layoutmgr TraitSetter.java
> BlockLayoutManager.java
>   Log:
>   Bugfix for start-indent calculation for nested blocks. The inherited 
> start-indent wasn't taken into account as described in 5.3.2 of the spec.
>   Minor style and javadoc improvements on the way.



>   Revision  ChangesPath
>   1.5   +34 -2 
> xml-fop/src/java/org/apache/fop/fo/properties/CommonMarginBlock.java
>   
>   Index: CommonMarginBlock.java
>   ===
>   RCS file: 
> /home/cvs/xml-fop/src/java/org/apache/fop/fo/properties/CommonMarginBlock.java,v
>   retrieving revision 1.4
>   retrieving revision 1.5
>   diff -u -r1.4 -r1.5
>   --- CommonMarginBlock.java  28 Oct 2004 10:00:24 -  1.4
>   +++ CommonMarginBlock.java  7 Jan 2005 08:21:21 -   1.5
>   @@ -1,5 +1,5 @@
>/*
>   - * Copyright 1999-2004 The Apache Software Foundation.
>   + * Copyright 1999-2005 The Apache Software Foundation.
> * 
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
>   @@ -70,6 +70,16 @@
>public Length endIndent;
>
>/**
>   + * The inherited "start-indent" property.
>   + */
>   +public Length inheritedStartIndent;
>   +
>   +/**
>   + * The inherited "end-indent" property.
>   + */
>   +public Length inheritedEndIndent;
>   +
>   +/**
> * Create a CommonMarginBlock object.
> * @param pList The PropertyList with propery values.
> */
>   @@ -84,5 +94,27 @@
>
>startIndent = pList.get(Constants.PR_START_INDENT).getLength();
>endIndent = pList.get(Constants.PR_END_INDENT).getLength();
>   +
>   +if (!pList.getFObj().generatesReferenceAreas()) {
>   +inheritedStartIndent = pList.getParentPropertyList()
>   +.get(Constants.PR_START_INDENT).getLength();
>   +inheritedEndIndent = pList.getParentPropertyList()
>   +.get(Constants.PR_END_INDENT).getLength();
>   +}
>   +}





Jeremias Maerki