DO NOT REPLY [Bug 40458] - difference between xsl used for FOP Verison 0.20.5 and 0.92(beta)

2006-09-10 Thread 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=40458


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-09-11 06:53 ---
If you have a question on Apache FOP please post that on the fop-users mailing
list [1]. Bugzilla is for bugs and keeping track of work items.

[1] http://xmlgraphics.apache.org/fop/maillist.html#fop-user

FOP 0.20.5 did many things wrong which FOP 0.92beta does much better. So if the
XSL-FO you generated for 0.20.5 doesn't work in 0.92beta it means your FO was
wrong and has to be improved. Details what needs to be changed can be found 
under:
http://xmlgraphics.apache.org/fop/0.92/upgrading.html
If this information doesn't help, please post log output and possibly an FO file
(not XSLT!) to the fop-users mailing list so people can give you some hints.

-- 
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 40442] - [PATCH] percent length not working in font-size for rtf output

2006-09-10 Thread 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=40442


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-09-11 06:48 ---
Creating LayoutManagers in RTF output is not really the right idea.
LayoutManagers are to be used only inside the "layout engine" which for RTF
isn't used. I realize it's a tempting move but from a design perspective, it is
wrong. A different solution has to be found. IMO, we have to have special
implementations for PercentBaseContext for output formats which don't use the
layout engine. These implementations could even be used by the layout managers,
thus removing the need to implement PercentBaseContext there.

If another committer disagrees with my statement, please reopen the issue.

-- 
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 40387] - PFMFile.load() crashes if a font has a name longer than 16 characters and also if parsing pfm files larger than 2048 bytes

2006-09-10 Thread 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=40387


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2006-09-11 06:40 ---
I've taken a look at your patch and the fix for the font name is clear enough.
However, the buffer parameter for the BufferedInputStream puzzles me. You add a
new method signature with a buffer parameter but you didn't also make a change
in PFMReader so that the official command-line tool profits from the change. It
looks more like you added this so you can work around the problem in your
environment. I'd prefer a more general fix if possible. So, should we simply
hard-code the buffer size to 16KB or something like that to avoid the seemingly
rare problem you're experiencing?

-- 
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 40458] New: - difference between xsl used for FOP Verison 0.20.5 and 0.92(beta)

2006-09-10 Thread 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=40458

   Summary: difference between xsl used for FOP Verison 0.20.5 and
0.92(beta)
   Product: Fop
   Version: 0.92
  Platform: Sun
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: pdf
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Can anyone Give me the difference between xsl used for FOP Verison 0.20.5 and 
0.92(beta).

Because when I have shifted the vesion 0.20.5 to 0.92(beta) but have not 
changed xsl file which I was previously using. so, it is not giving me data in 
0.92(beta) vesion but in 0.20.5 it is showing that data.

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

Bug report for Fop [2006/09/10]

2006-09-10 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font  |
| 1773|Opn|Blk|2001-05-16|A table that is bigger than the page produces an e|
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with  a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in |
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly  |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables   |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body  |
| 3497|New|Cri|2001-09-07|id already exists error when using span="all" attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling="uniform" does not work on images...  |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored?  |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG   |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 4814|Opn|Nor|2001-11-12|0.20.2RC infinitely loops if there are tables in f|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|New|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values   |
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|fi (fi ligature) produces a "sharp"? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render   |
| 6483|New|Nor|2002-02-15|Table, Loop, "footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect   |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space   |
| 7487|New|Nor|2002-03-26|break-before="page" for table inserts empty page  |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block  |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images  |
| 8050|New|Nor|2002-04-13|Soft hyphen (­) is not handled properly   |
| 8321|New|Nor|2002-04-19|from-parent('width') returns 0 for nested tables  |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
| 8767|Ass|Min|2002-05-03|Image

Re: Re: Configuration file problems

2006-09-10 Thread The Web Maestro 

On 9/10/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote:

On 10.09.2006 17:01:30 The Web Maestro wrote:
> On a related point, does it make sense that all configuration be
> handled in one place (e.g., fonts too)?

Can you explain further what you mean?


Sorry. For some reason I thought the FONT configuration was in a
different spot from normal FOP config. I re-read the FOP Config[1] &
the FONT configuration[2] sections again, and realized I was confusing
the PostScript & TrueType metrics file generation process with FOP's
configuration file.

Never mind!

[1] FOP Configuration:
http://xmlgraphics.apache.org/fop/0.92/configuration.html

[2] FOP Fonts Configuration:
http://xmlgraphics.apache.org/fop/0.92/fonts.html

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Configuration file problems

2006-09-10 Thread Jeremias Maerki 

On 10.09.2006 17:01:30 The Web Maestro wrote:
> We could just identify the schema in the DOCTYPE (or DTD if we decide
> to go that route--a schema is much more powerful, but isn't it more
> overhead?). Then, we could alter the location at will. Instead of
> embedding the file in FOP, it could be located either locally
> (relative to FOP or the XML files), or it could be located on a remote
> server.

Locating or specifying a DTD or an XML Schema is not the issue. We
already have an XML Schema we can use but XML Schema is not expressive
enough to properly validate the current configuration XML.

> As for validating, when someone creates a plug-in (or updates FOP to
> handle some new, configurable feature), one portion of the PATCH would
> update the fop-config.xsd file.

It's possible to assemble an ad-hoc XML Schema using the "import"
feature as needed (Renderers would contribute a sub-schema, for example),
but again, XML Schema is not expressive enough for the current format 
(distinction of a single element type by a "type" attribute, e.g.
"renderer"). The problem with the ad-hoc schema is that it's not
feasible for validation in an XML editor, only during FOP runtime.

> On a related point, does it make sense that all configuration be
> handled in one place (e.g., fonts too)?

Can you explain further what you mean?

Jeremias Maerki

Re: Re: Configuration file problems

2006-09-10 Thread The Web Maestro 

We could just identify the schema in the DOCTYPE (or DTD if we decide
to go that route--a schema is much more powerful, but isn't it more
overhead?). Then, we could alter the location at will. Instead of
embedding the file in FOP, it could be located either locally
(relative to FOP or the XML files), or it could be located on a remote
server.

As for validating, when someone creates a plug-in (or updates FOP to
handle some new, configurable feature), one portion of the PATCH would
update the fop-config.xsd file.

On a related point, does it make sense that all configuration be
handled in one place (e.g., fonts too)?

Clay

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Configuration file problems

2006-09-10 Thread Jeremias Maerki 
Ok, but with your statement you're carefully avoiding the topic about
how to actually validate the configuration. Are we then writing a number
of plug-ins which contain manually written code that verifies the config
file on the various levels (root, renderer, fonts)? Possible, not
difficult but takes quite a bit of work to get done.

On 10.09.2006 16:03:06 Manuel Mall wrote:
> On Sunday 10 September 2006 20:52, Jeremias Maerki wrote:
> > Ok, I consider myself defeated concerning the way we handle the
> > configuration file (See recent threads on fop-users). The Avalon
> > configuration approach is very nice for the developer but obviously
> > bullshit in terms of end-user-friendlyness. The attempt to overlay
> > the configuration layout with an XSD is generally a good idea but
> > with the current configuration layout, it's not a workable solution.
> >
> Not sure I agree with the "bleak" picture you are painting. In my 
> assessment most problems seem to be caused by the change of config 
> format from 0.20.5 to 0.9x. Not by the format itself.
> 
> What about having a command line option which triggers a config file 
> validation. Similar to Apache HTTPD:
> apachectl -t
> 
> "Run a configuration file syntax test. It parses  the  configura-
> tion  files and either reports Syntax Ok or detailed information
> about  the  particular  syntax  error."
> 
> Manuel
> > If anyone has a good plan to improve the situation, I'm all ears. I
> > think the configuration file needs to be built based on an XML Schema
> > and FOP should by default validate the configuration file (hard-coded
> > in FOP) so the users get proper feedback if they try to feed FOP with
> > an invalid format. But that means the XML Schema must be water-tight.
> > On the other side, we will probably lose extensibility of the
> > configuration file format. When someone adds his own renderer, for
> > example, he can't just have his own config values because he can't
> > change the XML Schema. So that may mean we probably can't use XML
> > Schema to validate the file. But then, maybe we can define the
> > individual renderer config parts as xsd:any or something like that
> > and let each renderer validate its own configuration (either manually
> > or using an XSD).
> >
> > ATM, I can't think of a good solution but apparently, we need to
> > change something at some point. Any ideas, thoughts?
> >
> > Jeremias Maerki



Jeremias Maerki

Re: Configuration file problems

2006-09-10 Thread Manuel Mall 
On Sunday 10 September 2006 20:52, Jeremias Maerki wrote:
> Ok, I consider myself defeated concerning the way we handle the
> configuration file (See recent threads on fop-users). The Avalon
> configuration approach is very nice for the developer but obviously
> bullshit in terms of end-user-friendlyness. The attempt to overlay
> the configuration layout with an XSD is generally a good idea but
> with the current configuration layout, it's not a workable solution.
>
Not sure I agree with the "bleak" picture you are painting. In my 
assessment most problems seem to be caused by the change of config 
format from 0.20.5 to 0.9x. Not by the format itself.

What about having a command line option which triggers a config file 
validation. Similar to Apache HTTPD:
apachectl -t

"Run a configuration file syntax test. It parses  the  configura-
tion  files and either reports Syntax Ok or detailed information
about  the  particular  syntax  error."

Manuel
> If anyone has a good plan to improve the situation, I'm all ears. I
> think the configuration file needs to be built based on an XML Schema
> and FOP should by default validate the configuration file (hard-coded
> in FOP) so the users get proper feedback if they try to feed FOP with
> an invalid format. But that means the XML Schema must be water-tight.
> On the other side, we will probably lose extensibility of the
> configuration file format. When someone adds his own renderer, for
> example, he can't just have his own config values because he can't
> change the XML Schema. So that may mean we probably can't use XML
> Schema to validate the file. But then, maybe we can define the
> individual renderer config parts as xsd:any or something like that
> and let each renderer validate its own configuration (either manually
> or using an XSD).
>
> ATM, I can't think of a good solution but apparently, we need to
> change something at some point. Any ideas, thoughts?
>
> Jeremias Maerki

Configuration file problems

2006-09-10 Thread Jeremias Maerki 
Ok, I consider myself defeated concerning the way we handle the
configuration file (See recent threads on fop-users). The Avalon
configuration approach is very nice for the developer but obviously
bullshit in terms of end-user-friendlyness. The attempt to overlay the
configuration layout with an XSD is generally a good idea but with the
current configuration layout, it's not a workable solution.

If anyone has a good plan to improve the situation, I'm all ears. I
think the configuration file needs to be built based on an XML Schema
and FOP should by default validate the configuration file (hard-coded in
FOP) so the users get proper feedback if they try to feed FOP with an
invalid format. But that means the XML Schema must be water-tight. On
the other side, we will probably lose extensibility of the configuration
file format. When someone adds his own renderer, for example, he can't
just have his own config values because he can't change the XML Schema.
So that may mean we probably can't use XML Schema to validate the file.
But then, maybe we can define the individual renderer config parts as
xsd:any or something like that and let each renderer validate its own
configuration (either manually or using an XSD).

ATM, I can't think of a good solution but apparently, we need to change
something at some point. Any ideas, thoughts?

Jeremias Maerki

DO NOT REPLY [Bug 40425] - PNG - Cannot read image dimensions

2006-09-10 Thread 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=40425


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-09-10 11:43 ---
Looks like a bug in the PNG codec for JDK 1.4.2_11 then. It may be this bug
here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4826548

As a work-around on JDK 1.4.2, you can change org.apache.fop.image.ImageFactory.
Find the line:
imt = new ImageMimeType("image/png");

...and change the block there to this:
imt = new ImageMimeType("image/png");
imageMimeTypes.put(imt.getMimeType(), imt);
imt.addProvider(pngImage);
imt.addProvider(imageIoImage);

This gives the internal PNG codec a higher priority over the ImageIO codec.

(In reply to comment #3)
> Right, running FOP with JDK 1.5 works :-) 
> 
> Building and running FOP using JDK 1.4.2_11 with the latest sources form the 
> SVN trunk, I get the following backtrace. The build proceeds, though, 
> resulting in a PDF document missing that image (which in fact is a black 
> square to simplify matters). 
> 
> 07.09.2006 10:10:09 org.apache.fop.image.ImageIOImage loadBitmap
> SCHWERWIEGEND: Error while loading image: 4
> java.lang.ArrayIndexOutOfBoundsException: 4
> at 
>
com.sun.imageio.plugins.png.PNGImageReader.parse_PLTE_chunk(PNGImageReader.java:347)

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