Re: Checking for OutputSource for renderer overrides

[Jeremias Maerki]

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. The
renderer knows best what it needs. 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.

Setting the OutputStream on the Fop class is merely a convenience method
that simplifies setup for normal cases. There are simply cases where no
OutputStream is needed. 

What I don't like is using RENDER_AWT or RENDER_PRINT just to specify
that I don't use an OutputStream. That's very unintuitive and misleading.
I see two possibilities: Adding a RENDER_CUSTOM constant or having a Fop
contructor without this constant.

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].

[1] http://jakarta.apache.org/commons/releases/versioning.html

On 07.01.2005 01:19:36 Glen Mazza wrote:
> Jeremias,
> 
> Per your change here [1], no longer checking for an
> OutputStream variable if the Renderer is overridden:
> The render constant chosen is irrelevant when the
> renderer is overridden.  So the embedded programmer
> can rely on RENDER_AWT or _PRINT for those
> comparatively rare cases of not needing an
> OutputStream (and, indeed, that would be the
> appropriate render type in most of those instances
> anyway.) 
> 
> People will be supplying an OutputSource for PDF-type
> generation--FOP has been requiring it for six years
> now with nary a complaint.  If you remove that check,
> and they forget to programmatically supply an output
> stream (a fairly common newbie mistake), errors in FOP
> will occur without informative messages.  
> 
> So I would advise the usage of RENDER_AWT/_PRINT for
> non-OutputStream usage for overridden renderers, while
> returning the check for the RENDER_PDF et al ones. 
> That should be sufficient for our next release, after
> which we can then consider "what's next" based on user
> feedback.
> 
> Glen
> 
> [1]
> http://marc.theaimsgroup.com/?l=fop-cvs&m=110495921529754&w=2



Jeremias Maerki

Checking for OutputSource for renderer overrides

[Glen Mazza]

Jeremias,

Per your change here [1], no longer checking for an
OutputStream variable if the Renderer is overridden:
The render constant chosen is irrelevant when the
renderer is overridden.  So the embedded programmer
can rely on RENDER_AWT or _PRINT for those
comparatively rare cases of not needing an
OutputStream (and, indeed, that would be the
appropriate render type in most of those instances
anyway.) 

People will be supplying an OutputSource for PDF-type
generation--FOP has been requiring it for six years
now with nary a complaint.  If you remove that check,
and they forget to programmatically supply an output
stream (a fairly common newbie mistake), errors in FOP
will occur without informative messages.  

So I would advise the usage of RENDER_AWT/_PRINT for
non-OutputStream usage for overridden renderers, while
returning the check for the RENDER_PDF et al ones. 
That should be sufficient for our next release, after
which we can then consider "what's next" based on user
feedback.

Glen

[1]
http://marc.theaimsgroup.com/?l=fop-cvs&m=110495921529754&w=2

Re: [RT] FOP RTF edition

[Simon Pepping]

On Wed, Jan 05, 2005 at 03:09:09PM -0800, Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to test the waters and see what you guys
> > think about separately
> > releasing the RTF part, or in other words: FOP RTF
> > edition. 
> 
> My $0.02:  Looks like busywork--I don't see how this
> would help you or any other committer.
> 
> I would be concerned about burdening current
> committers with this work, as well as scaring away
> prospective ones.  The deep thinkers that are needed
> to get layout et al done are generally not attracted
> to the mundane tasks that a FOP RTF would require.

I believe that releasing is a good thing as soon as we have a usable
product. But it is true that I am not very attracted to such a task at
the moment. Whether instead I am thinking deeply is quite another
matter :)

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

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-06 19:24 ---
comment to picture:
underlined text shoul be:
"nebo prevodem", "zvolene variante", "v pojistne"

-- 
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-06 19:21 ---
Created an attachment (id=13913)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13913&action=view)
Example of error. Interesting is that this error is accompanied by formatting
problem to which arrow is pointing


-- 
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] New: - 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

   Summary: Sticking words in generated PDF document
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: critical
  Priority: P2
 Component: pdf renderer
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


We are expriencing strange problem:

Documents generated using FOP 0.20.5 sticks words accidentaly in PDF document.

We are using FOP 0.20.5 to generate PDF documents using XSL and XML on command 
line and progrmmaticaly. We are using Java j2sdk1.4.1_02

Example:

code in XSL:
This text is example

In PDF is seen:
"Thistext is example"
or
"This textisexample"

When we open the same PDF document several times, it sticks different words 
sometimes, not the same each time. Occasionaly is text correct and not sticked. 
When we look in XSL, the text is correct.

Error can be produced only on large PDF files (our example has 5 pages) with 
long continuous text and many  sections.

We did try another XSL:FO processor - XEP 4.1 with the same XSL and XML files 
and it produces PDF without any formatting error. So it is why we assume, that 
error is in FOP.

We did test, that error can be produced on Adobe Acrobat Reader 5.0.0 CE, 5.0.5 
CE, 6.0.0 CE.
Error does not appear on AR 6.0.2 CE. But you can understood, we are not able 
to influence on users, which version of AR they will use...

In document we are using Arial font defined in userconfig and appropriate xml 
definition file.

If needed, I can provide more necessary informations as:
- XSL and XML example
- fop configuration 

Side effect of this error is GPF in AR sometimes.

Any help very wellcomed, because it looks to be serious problem for us.

-- 
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/test/layoutengine/testcases block-nested1.xml

[Jeremias Maerki]

This test currently fails because nested blocks don't respect the
inherited value of start-indent (XSL-FO 1.0, chapter 5.3.2). I already
have a fix locally but want to improve the code a bit, first, since
there is some amount of redundancy that can be reduced.

On 06.01.2005 17:09:57 jeremias wrote:
> jeremias2005/01/06 08:09:57
> 
>   Added:   test/layoutengine/testcases block-nested1.xml
>   Log:
>   Test for nested blocks with borders, margins and padding.


Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/properties BoxPropShorthandParser.java

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> 
> Using casts will prevent us from adding property
> proxies, which i 
> suspect will be needed.
> 

 What's a "property proxy"?  Can you 
elaborate on that--give a simple scenario of it?

Thanks,
Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/properties BoxPropShorthandParser.java

[Jeremias Maerki]

Sorry. Still learning. Thanks for paying attention. Fixed.

On 06.01.2005 13:33:08 Finn Bock wrote:
> [EMAIL PROTECTED] wrote:
> 
> >   Log:
> >   convertValueForProperty didn't have the right signature and
> >   therefore didn't override the superclass implementation.
> 
> That was sloppy of me. Thanks for finding and fixing it.
> 
> >   +ListProperty listProperty = (ListProperty)property;
> 
> That is a no-no. Properties should not be casted but only be coerced 
> using the getXXX methods.
> 
> And the getList() method is already defined on Property so no cast is 
> needed.
> 
> Using casts will prevent us from adding property proxies, which i 
> suspect will be needed.



Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/properties BoxPropShorthandParser.java

[Finn Bock]

[EMAIL PROTECTED] wrote:
  Log:
  convertValueForProperty didn't have the right signature and
  therefore didn't override the superclass implementation.
That was sloppy of me. Thanks for finding and fixing it.
  +ListProperty listProperty = (ListProperty)property;
That is a no-no. Properties should not be casted but only be coerced 
using the getXXX methods.

And the getList() method is already defined on Property so no cast is 
needed.

Using casts will prevent us from adding property proxies, which i 
suspect will be needed.

regards,
finn

Re: cvs commit: xml-fop/test/layoutengine/testcases padding2.xml

[Jeremias Maerki]

Looks like the new testing framework already has paid off. padding2.xml
tests border shorthands and currently shows a bug with shorthand
expansion. I'm happy (at least in a certain way).  Glen may
comment again that I'm particular. :-)

Now for fixing that bug

On 06.01.2005 10:47:46 jeremias wrote:
> jeremias2005/01/06 01:47:46
> 
>   Added:   test/layoutengine/testcases padding2.xml
>   Log:
>   Testing padding shorthands.


Jeremias Maerki