Re: Volunteer wanted - disabled-testcases.txt in XML

[Jeremias Maerki]

A single XML file as I showed it in my first post. That's more easily
processed later when we put this information on the website.

On 19.10.2005 00:22:39 Mark Gaywood wrote:
> Hi
> 
> Sorry for the delay, but I've got some clear evenings ahead.
> 
> With the text file (disabled-testcases.txt) are you envisioning a single xml
> replacement or one xml for each testcase?
> 
> Mark
> 
> -Original Message-
> 
> From: Jeremias Maerki [*mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]>]
> 
> 
> Sent: 15 October 2005 07:52
> 
> To: fop-dev@xmlgraphics.apache.org
> 
> Subject: Re: Volunteer wanted - disabled-testcases.txt in XML
> 
>  Only a couple of things to add to what Clay already handled.
> 
> On 15.10.2005 02:02:39 Mark Gaywood wrote:
> 
> > Jeremias,
> 
> >
> 
> > I'm set and ready to, just to be clear and I do apologise for not
> 
> > being on the ball straight away with what must appear to be a trivial
> 
> > task to most of you ,but I hope to up to your speeds and skill very
> 
> > soon.
> 
> >
> 
> > 1. convert the text file into an xml document with previously suggest
> 
> > markup
> 
> Yes.
> 
> > 2. modify decorateWithDisabledList to load the XML document
> 
> Yes.
> 
> > 3. filter the output of decorateWithDisabledList based a lookup passed
> 
> > in? Would it be too much to ask for you give me an example of an input
> 
> > and output for this method?
> 
> The mechanism in use here is the filefilter package from Jakarta Commons IO.
> You find the documentation here: *
> http://jakarta.apache.org/commons/io/api-release/index.html?org/apache/commons/io/filefilter/package-summary.html
> *
> 
> This method doesn't filter the files directly but decorates (See Design
> Patterns, "Gang of Four") an existing file filter so that the files listed
> in the file you're about to convert to XML won't get returned by the
> FileUtils.listFiles() methods (also a Commons IO thing). Basically, you're
> building a rule tree here. An example:
> 
> Assume a simple filter:
> 
> IOFileFilter myFilter = new PrefixFileFilter("my");
> 
> Passed into FileUtils.listFiles() this filter will return all files that
> start with "my", i.e. for example "myStuff.txt".
> 
> What you do in decorateWithDisabledList is something like that:
> 
> myFilter = new AndFilter(myFilter, new SuffixFileFilter(".xml"));
> 
> This will create a modified filter which restricts the existing file filter
> by adding the rule that all returned files must be XML files, so "
> myStuff.txt" wouldn't be returned anymore, but "myCalendar.xml" will still
> be returned.
> 
> Basically, you don't modify the filefilter rule at all, just the way the
> NameFileFilter in decorateWithDisabledList is constructed.
> 
> Run the whole thing through the debugger once and you'll understand how this
> works.
> 
> > 4. create some website with XSLT, Cocoon and Forrest (Nice)
> 
> Yes, if you want to do it.
> 
> > Will I need a password for login for submitting to SVN or would you
> 
> > prefer another method of code submission?
> 
> Just download the code using SVN and create patches as described in: *
> http://xmlgraphics.apache.org/fop/dev/#patches*
> 
> and
> 
> *http://xmlgraphics.apache.org/fop/dev/tools.html#patches*
> 
> and submit them using Bugzilla as Clay already told you.
> 
>  Jeremias Maerki
> <'fop-dev@xmlgraphics.apache.org'>



Jeremias Maerki

Re: White space handling Wiki page

[Manuel Mall]

On Wed, 19 Oct 2005 05:44 am, Jeremias Maerki wrote:
> I've started to comment on the individual issues you listed and only
> when I got to the examples I realized there must be something wrong.
> You place the white-space-treatment after the white-space-collapse
> but I think it is clear that the latter comes last ("during area tree
> construction" =after line breaking vs. "during line-building and
> inline-building" =before line-breaking). That's why you run into
> problems explaining why there is no line generated by the white space
> between the two starting block elements. Maybe clearing this up might
> clear up some of the other issues.
>
Jeremias,

yes I agree that this is a critical interpretation issue and I expected 
that part of the algorithm to be controversial. The problem is that in 
the description of value "true" for the white-space-collapse property 
it clearly refers to the fo tree and fo:character siblings in the tree. 
That was further clarified by an e-mail on the xsl editor list  
http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0004. Once 
we have done line-building the fo tree (at fo:character level) is 
largely gone, we have now glyph areas which could have been merged, 
ligatures combined, etc.. That means referring at this stage back to 
fo:character siblings in the fo tree seems lets say unusual. The fact 
that we are dealing with glyph areas and not fo:character elements in 
line-building / area tree construction is further emphasised by the 
description of the handling for the white-space-treatment property. It 
is all defined in terms of glyph areas not fo:characters.

Further to this it doesn't make sense to me to collapse white space 
after line breaking as is implied by your interpretation because the 
amount of white space does contribute to the line breaking decisions. 
If we remove white space after line breaking we would IMO get sub 
optimal line breaks. In summary I think white space must be collapsed 
before or at least during line breaking but not after.

Another related issue is the description of collapsing white space 
around a linefeed in the spec under white-space-collapse. The spec is 
very specific and refers to U+000A (linefeed) fo:character siblings in 
the fo tree. This is obviously very different to removing white space 
around a line break generated during line building. Also in the default 
case by the time we get to white-space-collapse handling all linefeeds 
would have been replaced by spaces during refinement. Which leads to 
the question do they really mean that in the spec or do they really 
meant to remove white space around a line break? But then again that is 
really dealt with by the white-space-treatment property in much more 
detail. But why then do we need the duplication of white-space-collapse 
removing white space around a linefeed character and 
white-space-treatment removing white space (not quite actually - it 
removes characters with the suppress-at-line-break property being true) 
around line breaks?


>> Manuel
>
> Jeremias Maerki

Manuel

RE: Volunteer wanted - disabled-testcases.txt in XML

[Mark Gaywood]

Hi
Sorry for the delay, but I've got some clear evenings ahead. 
With the text file (disabled-testcases.txt) are you envisioning a single xml replacement or one xml for each testcase?
Mark
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] 
Sent: 15 October 2005 07:52
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Volunteer wanted - disabled-testcases.txt in XML
 
Only a couple of things to add to what Clay already handled.
On 15.10.2005 02:02:39 Mark Gaywood wrote:
> Jeremias,
> 
> I'm set and ready to, just to be clear and I do apologise for not
> being on the ball straight away with what must appear to be a trivial 
> task to most of you ,but I hope to up to your speeds and skill very 
> soon.
> 
> 1. convert the text file into an xml document with previously suggest
> markup
Yes.
> 2. modify decorateWithDisabledList to load the XML document
Yes.
> 3. filter the output of decorateWithDisabledList based a lookup passed
> in? Would it be too much to ask for you give me an example of an input 
> and output for this method?
The mechanism in use here is the filefilter package from Jakarta Commons IO. You find the documentation here: 
http://jakarta.apache.org/commons/io/api-release/index.html?org/apache/commons/io/filefilter/package-summary.html
This method doesn't filter the files directly but decorates (See Design Patterns, "Gang of Four") an existing file filter so that the files listed in the file you're about to convert to XML won't get returned by the 
FileUtils.listFiles() methods (also a Commons IO thing). Basically, you're building a rule tree here. An example:
Assume a simple filter:
IOFileFilter myFilter = new PrefixFileFilter("my");
Passed into FileUtils.listFiles() this filter will return all files that start with "my", i.e. for example "myStuff.txt".
What you do in decorateWithDisabledList is something like that:
myFilter = new AndFilter(myFilter, new SuffixFileFilter(".xml"));
This will create a modified filter which restricts the existing file filter by adding the rule that all returned files must be XML files, so "myStuff.txt" wouldn't be returned anymore, but "myCalendar.xml
" will still be returned.
Basically, you don't modify the filefilter rule at all, just the way the NameFileFilter in decorateWithDisabledList is constructed.
Run the whole thing through the debugger once and you'll understand how this works.
> 4. create some website with XSLT, Cocoon and Forrest (Nice)
Yes, if you want to do it.
> Will I need a password for login for submitting to SVN or would you
> prefer another method of code submission?
Just download the code using SVN and create patches as described in: http://xmlgraphics.apache.org/fop/dev/#patches

and
http://xmlgraphics.apache.org/fop/dev/tools.html#patches
and submit them using Bugzilla as Clay already told you.
 
Jeremias Maerki

Re: SVG PDFTranscoder broken...

[Jeremias Maerki]

Thanks, I'll look into it tomorrow and will get back to you when I have
a good idea what's happening.

On 18.10.2005 22:58:59 thomas.deweese wrote:
> Hi Jeremias,
> 
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 10/18/2005 04:51:00 PM:
> 
> > I recently cleaned up the PDF and PS transcoders so they behave much
> > more similarly. I may have broken clipping then, although I have done
> > quite extensive tests. 
> 
>The problem isn't really with clipping, it's with the 'create'
> method of the Graphics interface.  I was pushed to use 'create'
> to deal with some clipping issues.
> 
> > Unfortunately, I can't quite follow your problem description. Would you
> > please post an example or describe how I can reproduce the
> > problem? I can then have a look at it. Thanks.
> 
>I suspect that attempting to render any SVG to PDF with
> trunk Batik will cause the problem (the root SVG element
> almost always has an associated clip - which causes the
> use of create).  I was specifically using the test file:
> samples/tests/spec/paints/linearGradientOrientation.svg
> 
>from the Batik source tree (I was going to work on fixing
> PDF Gradients when I noticed the problem).
> 
> > On 18.10.2005 19:28:24 thomas.deweese wrote:
> > > Hi all,
> > > 
> > >I don't know if you want to deal with this here in FOP land or over 
> in 
> > > Batik land but since the
> > > code in question is currently in FOP I thought I would start here. The 
> 
> > > PDF transcoder is
> > > currently broken.  This appears to be due to a recent change to the 
> way 
> > > clips are done.
> > > Previously a new clip was done something like:
> > > 
> > > Shape oldClip = g2d.getClip();  // get clip, in the current 
> > > coordinate system
> > > g2d.clip(newAdditiveClip);
> > > 
> > > // Draw things, blah blah
> > > 
> > > g2d.setClip(oldClip);  // restore clip, in current coordinate 
> > > system.
> > > 
> > > 
> > > This as it turns out has problems, the basic issue is that the 
> 
> > > clip can
> > > 'waver' as it is gotten and restored in various coordinate systems 
> (shift 
> > > one pixel left or 
> > > right).   To avoid  the need to get and restore the clip I started 
> using 
> > > the 'create' 
> > > method of the Graphics.  So the new code looks something like:
> > > 
> > > g2d = g2d.create();  // create new graphics 
> with 
> > > independent drawing state
> > > g2d.clip(newAdditiveClip);
> > > 
> > > // Draw things, blah blah
> > > 
> > > g2d.dispose();  // parent node will use 'old' graphics 2D.
> > > 
> > > 
> > > 
> > > The real code is a bit more complex than this but you get the
> > > idea.  The problem is that the PDFGraphics2D doesn't seem to properly
> > > implement 'create()'.  I've tried to hack this in but I get garbage 
> PDF 
> > > out.
> > > 
> > > So what I'm looking for is a basic analysis of how hard this 
> would
> > > be to fix, as well as suggestions on how to fix it.  There are some 
> other
> > > potential solutions to the wavering clip issue, although I think the 
> above 
> > > is
> > > by far the cleanest (and hence most desirable) of them.
> > 
> > 
> > 
> > Jeremias Maerki
> > 



Jeremias Maerki

Re: White space handling Wiki page

[Jeremias Maerki]

I've started to comment on the individual issues you listed and only
when I got to the examples I realized there must be something wrong. You
place the white-space-treatment after the white-space-collapse but I
think it is clear that the latter comes last ("during area tree construction"
=after line breaking vs. "during line-building and inline-building"
=before line-breaking). That's why you run into problems explaining why
there is no line generated by the white space between the two starting
block elements. Maybe clearing this up might clear up some of the other
issues.


On 18.10.2005 11:14:09 Manuel Mall wrote:
> I have started a white space handling Wiki page
> (http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling).
> 
> As with many other areas of the spec it seems to raise more questions than
> providing answers. I really would appreciate any comments, different views,
> clarifications, ... on what has been written so far.
> 
> Cheers
> 
> Manuel



Jeremias Maerki

Re: SVG PDFTranscoder broken...

[thomas . deweese]

Hi Jeremias,

Jeremias Maerki <[EMAIL PROTECTED]> wrote on 10/18/2005 04:51:00 PM:

> I recently cleaned up the PDF and PS transcoders so they behave much
> more similarly. I may have broken clipping then, although I have done
> quite extensive tests. 

   The problem isn't really with clipping, it's with the 'create'
method of the Graphics interface.  I was pushed to use 'create'
to deal with some clipping issues.

> Unfortunately, I can't quite follow your problem description. Would you
> please post an example or describe how I can reproduce the
> problem? I can then have a look at it. Thanks.

   I suspect that attempting to render any SVG to PDF with
trunk Batik will cause the problem (the root SVG element
almost always has an associated clip - which causes the
use of create).  I was specifically using the test file:
samples/tests/spec/paints/linearGradientOrientation.svg

   from the Batik source tree (I was going to work on fixing
PDF Gradients when I noticed the problem).

> On 18.10.2005 19:28:24 thomas.deweese wrote:
> > Hi all,
> > 
> >I don't know if you want to deal with this here in FOP land or over 
in 
> > Batik land but since the
> > code in question is currently in FOP I thought I would start here. The 

> > PDF transcoder is
> > currently broken.  This appears to be due to a recent change to the 
way 
> > clips are done.
> > Previously a new clip was done something like:
> > 
> > Shape oldClip = g2d.getClip();  // get clip, in the current 
> > coordinate system
> > g2d.clip(newAdditiveClip);
> > 
> > // Draw things, blah blah
> > 
> > g2d.setClip(oldClip);  // restore clip, in current coordinate 
> > system.
> > 
> > 
> > This as it turns out has problems, the basic issue is that the 

> > clip can
> > 'waver' as it is gotten and restored in various coordinate systems 
(shift 
> > one pixel left or 
> > right).   To avoid  the need to get and restore the clip I started 
using 
> > the 'create' 
> > method of the Graphics.  So the new code looks something like:
> > 
> > g2d = g2d.create();  // create new graphics 
with 
> > independent drawing state
> > g2d.clip(newAdditiveClip);
> > 
> > // Draw things, blah blah
> > 
> > g2d.dispose();  // parent node will use 'old' graphics 2D.
> > 
> > 
> > 
> > The real code is a bit more complex than this but you get the
> > idea.  The problem is that the PDFGraphics2D doesn't seem to properly
> > implement 'create()'.  I've tried to hack this in but I get garbage 
PDF 
> > out.
> > 
> > So what I'm looking for is a basic analysis of how hard this 
would
> > be to fix, as well as suggestions on how to fix it.  There are some 
other
> > potential solutions to the wavering clip issue, although I think the 
above 
> > is
> > by far the cleanest (and hence most desirable) of them.
> 
> 
> 
> Jeremias Maerki
> 

Re: Website refactoring

[Jeremias Maerki]

Hi Patrick,

if you can help add some meat to the bone, that would be appreciated.
This will basically involves copying the files from the 0.20.5 part and
adjusting them to the reality in FOP Trunk. I can imagine, though, that
this will not be a trivial task for someone who doesn't know the code
too well. I'll probably just take a day this week to put everything
together. If anyone offers help I won't say no. :-)

On 18.10.2005 19:55:26 Patrick Paul wrote:
> Hi,
> 
> I will be fixing the "BROKEN: No pipeline matched request:" warnings in 
> the next few days for the new "refactored" website.
> 
> If anyone has other requests or ideas for the new website I would be 
> glad to hear about them.
> 
> Have a nice day everyone.
> 
> Patrick Paul



Jeremias Maerki

Re: SVG PDFTranscoder broken...

[Jeremias Maerki]

Hi Thomas,

as long as the code is still here we probably have to deal with it here.
Migrating this stuff is pretty high on my list as soon we have the
preview release out which should happen real soon now.

I recently cleaned up the PDF and PS transcoders so they behave much
more similarly. I may have broken clipping then, although I have done
quite extensive tests. But then, we probably have to set up the same
kind of testing infrastructure we already have for FO.

Unfortunately, I can't quite follow your problem description. Would you
please post an example or describe how I can reproduce the
problem? I can then have a look at it. Thanks.

On 18.10.2005 19:28:24 thomas.deweese wrote:
> Hi all,
> 
>I don't know if you want to deal with this here in FOP land or over in 
> Batik land but since the
> code in question is currently in FOP I thought I would start here.  The 
> PDF transcoder is
> currently broken.  This appears to be due to a recent change to the way 
> clips are done.
> Previously a new clip was done something like:
> 
> Shape oldClip = g2d.getClip();  // get clip, in the current 
> coordinate system
> g2d.clip(newAdditiveClip);
> 
> // Draw things, blah blah
> 
> g2d.setClip(oldClip);  // restore clip, in current coordinate 
> system.
> 
> 
> This as it turns out has problems, the basic issue is that the 
> clip can
> 'waver' as it is gotten and restored in various coordinate systems (shift 
> one pixel left or 
> right).   To avoid  the need to get and restore the clip I started using 
> the 'create' 
> method of the Graphics.  So the new code looks something like:
> 
> g2d = g2d.create();  // create new graphics with 
> independent drawing state
> g2d.clip(newAdditiveClip);
> 
> // Draw things, blah blah
> 
> g2d.dispose();  // parent node will use 'old' graphics 2D.
> 
> 
> 
> The real code is a bit more complex than this but you get the
> idea.  The problem is that the PDFGraphics2D doesn't seem to properly
> implement 'create()'.  I've tried to hack this in but I get garbage PDF 
> out.
> 
> So what I'm looking for is a basic analysis of how hard this would
> be to fix, as well as suggestions on how to fix it.  There are some other
> potential solutions to the wavering clip issue, although I think the above 
> is
> by far the cleanest (and hence most desirable) of them.



Jeremias Maerki

Website refactoring

[Patrick Paul]

Hi,

I will be fixing the "BROKEN: No pipeline matched request:" warnings in 
the next few days for the new "refactored" website.


If anyone has other requests or ideas for the new website I would be 
glad to hear about them.


Have a nice day everyone.

Patrick Paul

SVG PDFTranscoder broken...

[thomas . deweese]

Hi all,

   I don't know if you want to deal with this here in FOP land or over in 
Batik land but since the
code in question is currently in FOP I thought I would start here.  The 
PDF transcoder is
currently broken.  This appears to be due to a recent change to the way 
clips are done.
Previously a new clip was done something like:

Shape oldClip = g2d.getClip();  // get clip, in the current 
coordinate system
g2d.clip(newAdditiveClip);

// Draw things, blah blah

g2d.setClip(oldClip);  // restore clip, in current coordinate 
system.


This as it turns out has problems, the basic issue is that the 
clip can
'waver' as it is gotten and restored in various coordinate systems (shift 
one pixel left or 
right).   To avoid  the need to get and restore the clip I started using 
the 'create' 
method of the Graphics.  So the new code looks something like:

g2d = g2d.create();  // create new graphics with 
independent drawing state
g2d.clip(newAdditiveClip);

// Draw things, blah blah

g2d.dispose();  // parent node will use 'old' graphics 2D.



The real code is a bit more complex than this but you get the
idea.  The problem is that the PDFGraphics2D doesn't seem to properly
implement 'create()'.  I've tried to hack this in but I get garbage PDF 
out.

So what I'm looking for is a basic analysis of how hard this would
be to fix, as well as suggestions on how to fix it.  There are some other
potential solutions to the wavering clip issue, although I think the above 
is
by far the cleanest (and hence most desirable) of them.

Re: Approaching a release?

[David Abrahams]

Jeremias Maerki <[EMAIL PROTECTED]> writes:

> If all had gone as planned we would have done the first preview release
> last month. As soon as I'm finished with my space resolution task
> (hopefully this week), I'm going to write all necessary documentation
> for the redesigned FOP and then we're pretty much ready to release.
> Note: alpha/preview release only!

Thanks for the update, and for your all your efforts!

P.S. when I wrote "alternative" I meant "alternative to LaTeX."

> On 12.10.2005 20:16:43 David Abrahams wrote:
>> 
>> As FOP is my only hope for a viable open-source alternative path to
>> PDF, I have been eagerly anticipating your next release.  Can anyone
>> give me a sense of how close (or far off) that might be?


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

DO NOT REPLY [Bug 37142] - Not able to apply subscript and superscript

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-10-18 14:56 ---
In fop 0.20.5, baseline-shift has not been implemented. However, you can use 
vertical-align="super" or vertical-align="sub" instead.

The 0.20.5 release will not be developed any further. A re-written 0.90 will 
be released in the next few weeks. So I'm closing this bug.

A polite request: please ask questions on the fop-user list before raising a 
bug as you will get an answer to your problem/question sooner.


-- 
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 37142] New: - Not able to apply subscript and superscript

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

   Summary: Not able to apply subscript and superscript
   Product: Fop
   Version: 0.20.5
  Platform: Sun
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P3
 Component: pdf renderer
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


superscript  and
subscript sample

these tags were supposed to create super and subscript but this was not happning
the resultant pdf file had only text but baseline was not changed

-- 
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 36977] - [PATCH]TextLayoutManager CJK line break

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-18 12:40 ---
The problem you mention (all the adjustment space appears at the end of the
line, in other words the line is not justified) is probably due to the bug 
36238.

Regards
Luca

-- 
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 37135] - [PATCH] Website refactoring

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-18 12:16 ---
Patch applied. I had to look at the xdocs.tar.gz you sent me off-line to
reproduce all the changes you've done. They didn't make it into the patch
somehow. The changes look good. I only changed from "1.0dev" to "0.90" as per
our release plan. With this I can now easily go into the details for the 0.90
documentation. Thanks Patrick!

http://svn.apache.org/viewcvs?rev=326073&view=rev

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

White space handling Wiki page

[Manuel Mall]

I have started a white space handling Wiki page
(http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling).

As with many other areas of the spec it seems to raise more questions than
providing answers. I really would appreciate any comments, different views,
clarifications, ... on what has been written so far.

Cheers

Manuel

DO NOT REPLY [Bug 37136] - external-graphic dimensions and rendering

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2005-10-18 09:38 ---
(In reply to comment #0)
> ==
> Sample1: The image will not be sized to the specified dimensions
> ==
> 
>  width="100.00mm" height="75.00mm">
>   
>  height="75.00mm"/>
>   
> 

This is something we've had a number of times now. The new FOP is much more
strict about the interpretation of the XSL specification and has much less wrong
behaviour than FOP 0.20.5. Under 0.20.5 the above probably did what you expected
it to do but it was a faulty interpretation of the specification. width and
height only specify the size of the box for the image, not the size of the
image. If you want to scale the image so that it fits into the prepared box you
will now have to add content-width="scale-to-fit". Otherwise, the image will be
painted in its intrinsic size. It is no bug in FOP.

> ==
> Sample2: The rendered PDF file fails to load, and fop reports exceptions
> 
> java.lang.RuntimeException: Some content could not fit into a line/page after 
> 50 attempts. Giving up to avoid an endless loop.
> Exception
> javax.xml.transform.TransformerException: java.lang.RuntimeException: Some 
> content could not fit into a line/page after 50 attempts. Giving up to avoid 
> an 
> endless loop.
> 
> ==
> 
> 
>   
> 

You get the above error message if an element on a page (in your case the image)
doesn't fit onto a page. The layout engine is then trying to put the element on
the next page and if it still doesn't fit on the next and so on. After 50
attempts it gives up and reports this. You will have to make sure that FOP is
able to fit the image into a page. Without a complete example to run it myself
it's difficult for me to tell you exactly what needs to be done. Try making the
image smaller to begin with.

BTW, the height property does not apply to the fo:block element. Your height
there will be ignored! Better specify the height on the external-graphic and use
content-width="scale-to-fit" as shown above.

If you don't manage with this information please reopen the bug and attach a
complete example file.

-- 
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 37136] - external-graphic dimensions and rendering

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





--- Additional Comments From [EMAIL PROTECTED]  2005-10-18 09:35 ---
Have you tried to use the content-height="scale-to-fit" and content-
width="scale-to-fit" on the fo:external-graphic?

FOP 1.0dev is attempting to be much more strict in applying the spec and will 
only scale if told to do so.

-- 
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 37136] New: - external-graphic dimensions and rendering

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

   Summary: external-graphic dimensions and rendering
   Product: Fop
   Version: 1.0dev
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: images
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


==
Sample1: The image will not be sized to the specified dimensions
==


  

  


==
Sample2: The rendered PDF file fails to load, and fop reports exceptions

java.lang.RuntimeException: Some content could not fit into a line/page after 
50 attempts. Giving up to avoid an endless loop.
Exception
javax.xml.transform.TransformerException: java.lang.RuntimeException: Some 
content could not fit into a line/page after 50 attempts. Giving up to avoid an 
endless loop.

==


  


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