DO NOT REPLY [Bug 16955] New: - Problems with hyphenation of menuchoice

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16955

Problems with hyphenation of menuchoice

   Summary: Problems with hyphenation of menuchoice
   Product: Fop
   Version: 0.20.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have following structure in my docbook-document

   
ProjectImport 
...

Unfortunately it occurs on the end-of-line, so Im-port must 
be splitted on two lines. In the pdf output (docbook 1.60.1 and fop 0.20.4), the word 
order changes 
to:

   bla-bla Im-
Project|port ...

It must be a fop-problem, because the intermediate fo-
file contains the following right code

Project|Import 
...

Cheers,
Tom

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16772] - Different JRE versions' affect on extent/margin(s)

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16772

Different JRE versions' affect on extent/margin(s)





--- Additional Comments From [EMAIL PROTECTED]  2003-02-11 08:43 ---
May it be concerned with the following bug, fixed in Java 1.3.1_07?

4263927  FontMetrics.stringWidth() in PrintGraphics was incorrect.

See:
http://java.sun.com/j2se/1.3/ReleaseNotes.html
http://developer.java.sun.com/developer/bugParade/bugs/4263927.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/org/apache/fop/configuration FontInfo.java

[jeremias]

jeremias2003/02/11 01:26:23

  Modified:src/org/apache/fop/configuration Tag: fop-0_20_2-maintain
FontInfo.java
  Log:
  Fixed copy/paste error. A confusing error message was constructed when the embedFile 
attribute was bad.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.2.5   +5 -3  xml-fop/src/org/apache/fop/configuration/Attic/FontInfo.java
  
  Index: FontInfo.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/configuration/Attic/FontInfo.java,v
  retrieving revision 1.2.2.4
  retrieving revision 1.2.2.5
  diff -u -r1.2.2.4 -r1.2.2.5
  --- FontInfo.java 8 Nov 2002 10:25:26 -   1.2.2.4
  +++ FontInfo.java 11 Feb 2003 09:26:23 -  1.2.2.5
  @@ -44,7 +44,8 @@
   try {
   return URLBuilder.buildURL(Configuration.getFontBaseURL(), metricsFile);
   } catch (Exception e) {
  -throw new FOPException("Invalid font metrics file: "+metricsFile+" 
("+e.getMessage()+")");
  +throw new FOPException("Invalid font metrics file: " + metricsFile 
  + + " (" + e.getMessage() + ")");
   }
   }
   
  @@ -57,7 +58,8 @@
   try {
   return URLBuilder.buildURL(Configuration.getFontBaseURL(), embedFile);
   } catch (Exception e) {
  -throw new FOPException("Invalid font file (embedFile): "+metricsFile+" 
("+e.getMessage()+")");
  +throw new FOPException("Invalid font file (embedFile): " + embedFile 
  + + " (" + e.getMessage() + ")");
   }
   }
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16957] New: - Broken link - please change

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16957

Broken link - please change

   Summary: Broken link - please change
   Product: Fop
   Version: all
  Platform: Other
   URL: http://xml.apache.org/fop/relnotes.html
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Please change the "JAI" link from
  http://java.sun.com/products/java-media/jai/JAI
to
  http://java.sun.com/products/java-media/jai/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

ANN: FOA new release: 0.5.0

[Giannetti, Fabio]

Hello,
FOA (Formatting Object Authoring tool) 
http://foa.sourceforge.net
has a new release: 0.5.0.
The new features for this release are:
- New Bricks:
  - Block and Inline Containers
  - Footnotes
  - Floats
  - External (Foreign) Objects
  - Leaders
- New Support:
  - Table Caption
  - Hyphenation
  - Background Image

You can find more details on the FO supported at:
http://foa.sourceforge.net/supportedFOs.html
and properties at:
http://foa.sourceforge.net/supportedProperties.html

Best Regards,
Fabio Giannetti

CC: W3C XSL-FO, FOP DEV, Yahoo XSL-FO

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/org/apache/fop/render AbstractRenderer.java

[jeremias]

jeremias2003/02/11 06:04:35

  Modified:src/org/apache/fop/render Tag: fop-0_20_2-maintain
AbstractRenderer.java
  Log:
  Fixes a cause for a NPE. Doesn't fix the obvious bug, though.
  
  Bug can be reproduced with the FO file in:
  http://marc.theaimsgroup.com/?l=fop-user&m=104497021323551&w=2
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.2.8   +6 -3  xml-fop/src/org/apache/fop/render/AbstractRenderer.java
  
  Index: AbstractRenderer.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/AbstractRenderer.java,v
  retrieving revision 1.4.2.7
  retrieving revision 1.4.2.8
  diff -u -r1.4.2.7 -r1.4.2.8
  --- AbstractRenderer.java 11 Jan 2003 18:43:04 -  1.4.2.7
  +++ AbstractRenderer.java 11 Feb 2003 14:04:35 -  1.4.2.8
  @@ -451,9 +451,12 @@
* @param area area to render
*/
   public void renderLineArea(LineArea area) {
  -if (area.pendingWidth>0) {
  +if (area.pendingWidth > 0) {
  + final String pageNumber = (area.getPage() != null 
  + ? area.getPage().getFormattedNumber()
  + : "");
   log.error("Areas pending, text probably lost. Check Page " +
  -  area.getPage().getFormattedNumber() +
  +  pageNumber +
 " and following page.");
   }
   int rx = this.currentAreaContainerXPosition + area.getStartIndent();
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13464] - part of word missing when broken across pages

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464

part of word missing when broken across pages





--- Additional Comments From [EMAIL PROTECTED]  2003-02-11 14:42 ---
Another occurence of this bug can be found here:
http://marc.theaimsgroup.com/?t=10143129755&r=1&w=2
and
http://marc.theaimsgroup.com/?t=10449738486&r=1&w=2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: source for hz algorithm

[Victor Mote]

FYI, I now have the Knuth books "Digital Typography" and the 5-volume
"Computers & Typesetting", and have perused the relevant sections. The h & j
algorithm that I have been looking for can be found in Chapter 3 of "Digital
Typography". A brief history of line-breaking is included, as well as a
discussion of the theory, and the algorithm laid out in pretty good detail.
The mathematics of the solution will appeal to Rhett and probably several
others. The performance penalty is not so great as I thought. Here is an
excerpt:

<-- Start -->
But how is the computer to solve such a problem efficiently? When a given
paragraph has n optional breakpoints, there are 2^n ways to break it into
lines, and even the fastest conceivable computers could not run through all
such possibilities in a reasonable amount of time. In fact, the job of
breaking a paragraph into equal-sized lines as nicely as possible sounds
suspiciously like the infamous bin-packing problem, which is well known to
be NP-complete. Fortunately, however, each line will consist of contiguous
information from the paragraph, so the line-breaking problem is amenable to
the techniques of discrete dynamic programming; hence there is a reasonably
efficient way to attack it. We shall see that the optimum breakpoints can be
found in practice with only about twice as much computation as needed by the
traditional algorithm; the new method is sometimes even faster than the old,
when we consider the time saved by not needing to hyphenate so often
<-- End -->

For any who are interested in line-breaking, I highly recommend at least
reading through this material. The book has a lot of other interesting
things as well, including a chapter (4) on bidi.

I'm hoping to be back into doing real work within a few days.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: include file in XSL

[Athalye, Rishi]

Clay,
I do know about xsl:include, import, etc. I was trying to include common
content at different locations within the page(s) for which this does not
work.
I solved this issue by putting that content in an XML file and calling
document() from within my xsl:value-of tag.
However, that added a requirement of having that content in XML format.
This is not necessary in your normal HTML includes.
I know there are several ways of achieving this in HTML, but I wanted
something which will work for the PDF (FO)version.

I do think this was the right forum for such a question. Please read the
question properly in the future and you will save effort in typing the
educational pointers.

Rishi


-Original Message-
From: Clay Leeds [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 10, 2003 5:18 PM
To: [EMAIL PROTECTED]
Subject: Re: include file in XSL


Rishi,

An xsl:include element exists:

http://www.w3schools.com/xsl/el_include.asp

NOTE: it must exist only as a child of xsl:stylesheet or xsl:transform. 
In other words, it must appear just below the root xsl:stylesheet element.

There is also xsl:import which is similar. I recommend picking up an XSL 
  or XML book that explains how to use such things. You can also search 
google.com (like I did for this post), for more information and tutorials.

Web Maestro Clay

p.s. Please make sure you post to the right place. fop-dev is where FOP 
Development is discussed. fop-user *might* be OK for this type of 
question, but xsl-list is the best. You can find out more about where to 
post questions on this page (in the links on the left):

http://xml.apache.org/fop/gethelp.html

p.p.s. Please take a look at this link "How to Ask Questions the Smart 
Way" for more info: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Athalye, Rishi wrote:
> Hi,
> 
> We are creating a PDF by applying the XSL to the data (XML). We are 
> using several XSLs which present the data in different formats. There 
> is some content which is common for all these XSLs. Can I do something 
> similar to what is achievable via an include directive in HTML.
> Thus, I would not have to hard-code the common content in each XSL, but it
> could lie in a common include file and all these XSL's would
> include it before sending it to the FO PDF renderer.
> 
> I would appreciate any help.
> 
> Thanks.
> 
> 
> Rishi Athalye
> [EMAIL PROTECTED]


-- 
Clay Leeds - [EMAIL PROTECTED]
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: include file in XSL

[Clay Leeds]

Hi Rishi,

Athalye, Rishi wrote:

Clay,
I do know about xsl:include, import, etc. I was trying to include common
content at different locations within the page(s) for which this does not
work.
I solved this issue by putting that content in an XML file and calling
document() from within my xsl:value-of tag.
However, that added a requirement of having that content in XML format.
This is not necessary in your normal HTML includes.


Since FOP processes XSL (which must be well-formed XML), as I understand 
it, whatever it processes must be well-formed XML. xsl:value-of or 
xsl:copy-of might be solutions which would work, however, content will 
still need to be valid (although if the "include" were merely text, it 
is conceivable it could be grabbed in the way you described.

I know there are several ways of achieving this in HTML, but I wanted
something which will work for the PDF (FO)version.


Sounds like using document() will work, although the definition of 
document() implies grabbing an XML document:

http://www.w3.org/TR/xslt#document

  Function: node-set document(object, node-set?)

  The document function allows access to XML
  documents other than the main source document.

Of course, you could be asking for a way to have the object not 
necessarily be a well-formed XML document. Sorry, I don't know.

I do think this was the right forum for such a question. Please read the
question properly in the future and you will save effort in typing the
educational pointers.

Rishi


Sorry, I still think your post does not appear to relate to the 
development of FOP, but rather relates to the use of FOP, I still think 
this is not the appropriate forum for this discussion. If I am 
incorrect, and this issue relates to the *development* of fop-dev (see 
list descriptions below), please forgive me.

Respectfully,

Web Maestro Clay

http://xml.apache.org/fop/resources.html

FOP User Mailing List ([EMAIL PROTECTED]) - Use this forum to 
discuss topics of interest to FOP users. After reviewing the FOP 
documentation and searching the archives (see below), use this forum to 
ask questions about how to download, install, configure, and use FOP. 
Please do not use this forum for general XSL-FO, XSLT, or PDF questions.

FOP Developer Mailing List ([EMAIL PROTECTED]) - Use this forum to 
discuss topics related to FOP development, including patch submissions, 
bug reports, and design issues.

Good luck!

-Original Message-
From: Clay Leeds [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 10, 2003 5:18 PM
To: [EMAIL PROTECTED]
Subject: Re: include file in XSL


Rishi,

An xsl:include element exists:

http://www.w3schools.com/xsl/el_include.asp

NOTE: it must exist only as a child of xsl:stylesheet or xsl:transform. 
In other words, it must appear just below the root xsl:stylesheet element.

There is also xsl:import which is similar. I recommend picking up an XSL 
  or XML book that explains how to use such things. You can also search 
google.com (like I did for this post), for more information and tutorials.

Web Maestro Clay

p.s. Please make sure you post to the right place. fop-dev is where FOP 
Development is discussed. fop-user *might* be OK for this type of 
question, but xsl-list is the best. You can find out more about where to 
post questions on this page (in the links on the left):

http://xml.apache.org/fop/gethelp.html

p.p.s. Please take a look at this link "How to Ask Questions the Smart 
Way" for more info: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Athalye, Rishi wrote:

Hi,

We are creating a PDF by applying the XSL to the data (XML). We are 
using several XSLs which present the data in different formats. There 
is some content which is common for all these XSLs. Can I do something 
similar to what is achievable via an include directive in HTML.
Thus, I would not have to hard-code the common content in each XSL, but it
could lie in a common include file and all these XSL's would
include it before sending it to the FO PDF renderer.

I would appreciate any help.

Thanks.


Rishi Athalye
[EMAIL PROTECTED]


--
Clay Leeds - [EMAIL PROTECTED]
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: include file in XSL

[Oleg Tkachenko]

Athalye, Rishi wrote:


I do think this was the right forum for such a question.

Sorry, Rishi, but XSL include questions are really offopic in the mail list 
devoted to FOP development. Please ask your question in xsl-list, see 
http://www.mulberrytech.com/xsl/xsl-list/index.html.
--
Oleg Tkachenko
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: cvs commit: xml-fop/src/org/apache/fop/render AbstractRenderer.java

[J.Pietschmann]

[EMAIL PROTECTED] wrote:

  Fixes a cause for a NPE. Doesn't fix the obvious bug, though.
  +	final String pageNumber = (area.getPage() != null 

Dammit, does this mean the page can be already null?
In this case the following:


   log.error("Areas pending, text probably lost. Check Page " +
  +  pageNumber +


is basically useless. "Check Page ...", this would
drive me crazy for certain. Are there cases where a page
number was actually shown?
The dropped text could be retrieved from the pending area,
however, I think a page number to check would be really
useful too.

Also, why does this problem get so much attention recently?
It was mentioned only three or four times in two years!

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: source for hz algorithm

[Oleg Tkachenko]

Victor Mote wrote:

FYI, I now have the Knuth books "Digital Typography" and the 5-volume
"Computers & Typesetting", and have perused the relevant sections. The h & j



For any who are interested in line-breaking, I highly recommend at least
reading through this material. The book has a lot of other interesting
things as well, including a chapter (4) on bidi.

I've got this book too, good one, but too TeX-oriented IMO. Funny enough, the 
book was lying on my desk for ages and only now I noted it has a  very 
interesting chpater about line breaking ;)
--
Oleg Tkachenko
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: source for hz algorithm

[Victor Mote]

Oleg Tkachenko wrote:

> I've got this book too, good one, but too TeX-oriented IMO.

True enough that the book in general is TeX- & Metafont-oriented. However, I
thought the chapter on line-breaking was general enough to be very useful to
us.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: cvs commit: xml-fop/src/org/apache/fop/render AbstractRenderer.java

[Jeremias Maerki]

On 11.02.2003 19:10:16 J.Pietschmann wrote:
> [EMAIL PROTECTED] wrote:
> >   Fixes a cause for a NPE. Doesn't fix the obvious bug, though.
> >   + final String pageNumber = (area.getPage() != null 
> 
> Dammit, does this mean the page can be already null?

Sounds like it. :-)

> In this case the following:
> 
> >log.error("Areas pending, text probably lost. Check Page " +
> >   +  pageNumber +
> 
> is basically useless. "Check Page ...", this would
> drive me crazy for certain. Are there cases where a page
> number was actually shown?

Not in the example I've examined today.

> The dropped text could be retrieved from the pending area,
> however, I think a page number to check would be really
> useful too.

When I tracked down the bug, I tought a function on LineArea would be
nice that constructs a String from its children so you get some context
in your FO file.

> Also, why does this problem get so much attention recently?
> It was mentioned only three or four times in two years!

Does it? Well, bugs are bugs, but it bugs me that they still distract us
so much from the redesign. Wouldn't life be beautiful if we didn't have
to provide support? Just kidding.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6094] - 0.20.3rc hangs in endless loop

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=6094

0.20.3rc hangs in endless loop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-02-11 19:36 ---
No, label-end() *was* computed. The problem was that the guy set
provisional-distance-between-starts="1em" which is too small for anything
and causes an infinite loop in Block.layout(), happily adding empty lines.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16955] - Problems with hyphenation of menuchoice

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16955

Problems with hyphenation of menuchoice

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-02-11 19:46 ---
This is fixed in 0.20.5rc. But see also #13464.

*** This bug has been marked as a duplicate of 2106 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 2106] - broken justification with numeric umlaut entities

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106

broken justification with numeric umlaut entities

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-02-11 19:46 ---
*** Bug 16955 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6094] - 0.20.3rc hangs in endless loop

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=6094

0.20.3rc hangs in endless loop





--- Additional Comments From [EMAIL PROTECTED]  2003-02-11 19:46 ---
Could someone confirm that the endless loop terminator in 0.20.5 does not catch 
this?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/org/apache/fop/fo/expr LabelEndFunction.java

[pietsch]

pietsch 2003/02/11 11:47:25

  Modified:src/documentation/content/xdocs Tag: fop-0_20_2-maintain
relnotes.xml
   src/org/apache/fop/fo/expr Tag: fop-0_20_2-maintain
LabelEndFunction.java
  Log:
  Fixed JAI URL.
  PR:16957
  Submitted by: ole.kvarno
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.3   +1 -1  xml-fop/src/documentation/content/xdocs/relnotes.xml
  
  Index: relnotes.xml
  ===
  RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/relnotes.xml,v
  retrieving revision 1.3.2.2
  retrieving revision 1.3.2.3
  diff -u -r1.3.2.2 -r1.3.2.3
  --- relnotes.xml  10 Dec 2002 10:06:36 -  1.3.2.2
  +++ relnotes.xml  11 Feb 2003 19:47:25 -  1.3.2.3
  @@ -26,7 +26,7 @@
   copy JimiProClasses.zip to FOP's lib dir and rename it to jimi-1.0.jar.
   
   Fop has been compiled with
  -http://java.sun.com/products/java-media/jai/JAI";>JAI
  +http://java.sun.com/products/java-media/jai";>JAI
   support. For using JAI you just need to install it.
   
   Links in PDF won't generate multiple link rectangles anymore. If this causes
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.2.2.2   +4 -7  xml-fop/src/org/apache/fop/fo/expr/LabelEndFunction.java
  
  Index: LabelEndFunction.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/expr/LabelEndFunction.java,v
  retrieving revision 1.2.2.1
  retrieving revision 1.2.2.2
  diff -u -r1.2.2.1 -r1.2.2.2
  --- LabelEndFunction.java 17 Feb 2002 19:53:36 -  1.2.2.1
  +++ LabelEndFunction.java 11 Feb 2003 19:47:25 -  1.2.2.2
  @@ -1,8 +1,8 @@
   /*
* $Id$
  - * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
  - * For details on use and redistribution please refer to the
  - * LICENSE file included with these sources.
  + * Copyright (C) 2001-2003 The Apache Software Foundation. All rights
  + * reserved.  For details on use and redistribution please refer to
  + * the LICENSE file included with these sources.
*/
   
   package org.apache.fop.fo.expr;
  @@ -47,9 +47,6 @@
   labelEnd.addTerm(-1.0, distance);
   labelEnd.addTerm(-1.0, startIndent);
   labelEnd.addTerm(1.0, separation);
  -
  -// make sure value gets calculated
  -labelEnd.computeValue();
   
   return new LengthProperty(labelEnd);
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Throwing away code was: Re: cvs commit:

[J.Pietschmann]

Jeremias Maerki wrote:

Dammit, does this mean the page can be already null?

Sounds like it. :-)

Where the hell is it nulled? I can't find it!


When I tracked down the bug, I tought a function on LineArea would be
nice that constructs a String from its children so you get some context
in your FO file.

Hmhm.


Does it? Well, bugs are bugs, but it bugs me that they still distract us
so much from the redesign. Wouldn't life be beautiful if we didn't have
to provide support? Just kidding.


Actually, the way the redesign was attempted was probably a
bad idea. See
 http://www.joelonsoftware.com/articles/fog69.html

Seems we have now the worst of all, with a reasonably working
but outdated code in the maintenace branch and a huge investment,
but still not fully working code in HEAD :-(

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 6094] - 0.20.3rc hangs in endless loop

[J.Pietschmann]

[EMAIL PROTECTED] wrote:

Could someone confirm that the endless loop terminator in 0.20.5 does not catch 
this?

Yes.
The loop seems to be in FOText.addRealText, where empty, zero height
lines are added generated. This could be a bug in LineArea around
line 667, where text is added to the line because the first word
on the line overfolws and couln't be hyphenated. Shouldn't text
added only after a break opportunity was encountered? This code is
ghoulish!

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: cvs commit: xml-fop/src/org/apache/fop/fo/expr LabelEndFunction.java

[J.Pietschmann]

[EMAIL PROTECTED] wrote:

  Modified:src/documentation/content/xdocs Tag: fop-0_20_2-maintain
relnotes.xml
   src/org/apache/fop/fo/expr Tag: fop-0_20_2-maintain
LabelEndFunction.java
  Log:
  Fixed JAI URL.


Oops, sorry for screwing the committ message. The LabelEndFunction
fix undoes the 6094 fix and makes label-end() work again.

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Throwing away code was: Re: cvs commit:

[Jeremias Maerki]

On 11.02.2003 20:55:40 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> >>Dammit, does this mean the page can be already null?
> > Sounds like it. :-)
> Where the hell is it nulled? I can't find it!

It is never set. Area.setPage() is never called for LineAreas or so
Eclipse tries to tell me.

> > When I tracked down the bug, I tought a function on LineArea would be
> > nice that constructs a String from its children so you get some context
> > in your FO file.
> Hmhm.

:-)

> > Does it? Well, bugs are bugs, but it bugs me that they still distract us
> > so much from the redesign. Wouldn't life be beautiful if we didn't have
> > to provide support? Just kidding.
> 
> Actually, the way the redesign was attempted was probably a
> bad idea. See
>   http://www.joelonsoftware.com/articles/fog69.html
>
> Seems we have now the worst of all, with a reasonably working
> but outdated code in the maintenace branch and a huge investment,
> but still not fully working code in HEAD :-(

We took a decision and I can still live with it. Nobody said it would be
easy. Of course, it would be nice if we got some more resources in form
of people working on the redesign or even funding to developers or
committers... The biggest problem is probably that we lost a lot of
knowledge (and possble workpower) when important committers left. At
least you can say that the redesign holds some promising prespectives 
(IMO).

Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

FopServlet example!

[Ken Masters]

Hi everyone,

I am new to Apache FOP, and am finding a little problem with what I'm doing. 
The XSLTInputHandler class has two parameters, the XML and XSL File's. 
Basically what I would like to do is pass an XML as a Java String (since it 
is dynamically created) and the XSL can be passed as a File.

How would I go about doing something like this, where the XML is created 
dynamically by a Servlet (from an XML database,Apache-Xindice), and passing 
this onto the XSLTInputHandler class (or any other class).

Thanking you in advance!

Ken



_
Overloaded with spam? With MSN 8, you can filter it out 
http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: FopServlet example!

[Mark C. Allman]

Write your own InputHandler to do what you need.  Then do the usual
driver.render() call:

Driver driver = new Driver();

InputHandler inputHandler =
new MyCustomInputHandler(..whatever your InputHandler needs..);

driver.setOutputStream(..wherever you want the output to go..);
driver.render(inputHandler.getParser(),
inputHandler.getInputSource());

-- Mark C. Allman
-- Allman Professional Consulting, Inc.
-- www.allmanpc.com, 617-947-4263


-Original Message-
From: Ken Masters [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, February 11, 2003 4:16 PM
To: [EMAIL PROTECTED]
Subject: FopServlet example!

Hi everyone,

I am new to Apache FOP, and am finding a little problem with what I'm
doing. 
The XSLTInputHandler class has two parameters, the XML and XSL File's. 
Basically what I would like to do is pass an XML as a Java String (since
it 
is dynamically created) and the XSL can be passed as a File.

How would I go about doing something like this, where the XML is created

dynamically by a Servlet (from an XML database,Apache-Xindice), and
passing 
this onto the XSLTInputHandler class (or any other class).

Thanking you in advance!

Ken



_
Overloaded with spam? With MSN 8, you can filter it out 
http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1
059


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FopServlet example!

[J.Pietschmann]

Ken Masters wrote:

I am new to Apache FOP, and am finding a little problem with what I'm 
doing. The XSLTInputHandler class has two parameters, the XML and XSL 
File's. Basically what I would like to do is pass an XML as a Java 
String (since it is dynamically created) and the XSL can be passed as a 
File.

FAQ:
  http://xml.apache.org/fop/faq.html#faq-N102B3

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Throwing away code was: Re: cvs commit:

[Victor Mote]

Jeremias Maerki wrote:

> On 11.02.2003 20:55:40 J.Pietschmann wrote:

...

> > Actually, the way the redesign was attempted was probably a
> > bad idea. See
> >   http://www.joelonsoftware.com/articles/fog69.html
> >
> > Seems we have now the worst of all, with a reasonably working
> > but outdated code in the maintenace branch and a huge investment,
> > but still not fully working code in HEAD :-(
>
> We took a decision and I can still live with it. Nobody said it would be
> easy. Of course, it would be nice if we got some more resources in form
> of people working on the redesign or even funding to developers or
> committers... The biggest problem is probably that we lost a lot of
> knowledge (and possble workpower) when important committers left. At
> least you can say that the redesign holds some promising prespectives
> (IMO).

Sorry, I have to agree with Joerg here, although I have no desire to reopen
the issue. I would rather have done a million refactorings to get us where
we want to go than to maintain two sets of code. I think that the reason
resources are not forthcoming is because of the barriers to entry that we
have raised, the largest being that, if you want to work on the code, you
really only get to work on the code that doesn't run. For most people, that
is a no starter. I think when the trunk works reasonably well, resources
will appear again.  The sine qua non
of open source software is that the code works. Any experimental code that
doesn't work but needs to get checked in should go onto a branch until it
works. Commercial software developers might be able to get away with a
different approach, if they hold enough cash in their hand to buy the
resources to get them across the hump. The transitory nature of open source
resources dictates that every incremental change (on the trunk anyway) be
pretty much logically complete, and (by intention anyway) better /even in
the short term/ than what was there before.

All of that said, I am committed to the redesign, and frankly can't wait to
get back to it. This is not only an extraordinary project, but it has an
extraordinary crew (but let's don't ever do it this way again ... please).

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]