We've tried out latest SVN code and get this lines when rendering a specific FO file to PDF. The FO actually seems to be correct (it gets produced by a third party tool, and gets rendered well with FOP-0.20.5). So is this a bug us *us*, of *the tool vendor*, or of *fop* actually?
There's the same problem with the following messages: 'The contents of row 1 are taller than they should be (there is a block-progression-dimension or height constraint on the indicated row). Due to its contents the row grows to 127558 millipoints, but the row shouldn't get any taller than MinOptMax[min=opt=max=70866] millipoints.' and 'Invalid ICC profile: java.lang.IllegalArgumentException: Invalid ICC Profile Data java.lang.IllegalArgumentException: Invalid ICC Profile Data' We actually don't know if *we* have done something wrong, or the *tool vendor* or *fop*, so we need your help to clarifiy this.
(In reply to comment #0) > We've tried out latest SVN code and get this lines when rendering a specific FO > file to PDF. The FO actually seems to be correct (it gets produced by a third > party tool, and gets rendered well with FOP-0.20.5). > > So is this a bug us *us*, of *the tool vendor*, or of *fop* actually? Your FO is probably correct and you get the warning message "table-layout="fixed" and width="auto", but auto-layout not supported => assuming width="100%"" to inform you that FOP doesn't support the automatic table layout and instead uses the fixed table layout, because even though you specified table-layout="fixed", the spec says in 6.7.3 that the automatic table layout is to be used when the inline-progression-dimension (or width) is not specified. So this is no bug, but actually a feature to handle your FO even though automatic table layout is not yet available. Simply specify a width for your table and the warning message goes away. Or simply ignore the warning.
(In reply to comment #1) > There's the same problem with the following messages: > > 'The contents of row 1 are taller than they should be (there is a > block-progression-dimension or height constraint on the indicated row). Due to > its contents the row grows to 127558 millipoints, but the row shouldn't get any > taller than MinOptMax[min=opt=max=70866] millipoints.' This tells you that you have a logical error in your FO file. You specify the height of either a table-cell or table-row which also sets the maximum to that value. Now, the contents of one of the cells is larger than your specified maximum and therefore you get an error. The row will still automatically grow. This is only a warning to you. Some users might want to have this reported as an error in the future. Note that FOP Trunk is much more strict about the interpretation of the specification. Therefore, it is likely that you'll get more warning messages, but you have to make the difference between warnings and errors. To get rid of the warning message use block-progression-dimension.minimum instead of height. That will leave the maximum on the value "auto" which allows the row to grow as needed. > and > > 'Invalid ICC profile: java.lang.IllegalArgumentException: Invalid ICC Profile Data > java.lang.IllegalArgumentException: Invalid ICC Profile Data' > > We actually don't know if *we* have done something wrong, or the *tool vendor* > or *fop*, so we need your help to clarifiy this. That's not an error message from FOP. I assume you embed a JPEG image with an ICC profile and someone has a problem with it. If you attach that image I can take a look at it.
Created attachment 16597 [details] Icon for ICC-Problem This is the picture we are using to produce the ICC problem.
Some more infos for the 'ICC Profile' problem: It seems as if there is a problem with file:// typed URLs. We have put in the following URL: file://localhost/C:/myfolder/myfile.jpg and it tells us it cannot find the file (java.io.FileNotFoundException). If we put that URL in a browser, it shows the picture. If we change the URL to 'file:myfile.jpg', then no exception is shown, but the ICC error is posted. So despite the ICC problem there is a problem using file URLs? Maybe you like to check the picture, please find it attached.
Looks like we don't parse the host part of the URL when creating a java.io.File from the URL. Want to fix this and send a patch? The JPEG image you attached works fine for me, BTW. I can't reproduce the problem.
I tried under Linux a "file://localhost/..." URL and it worked fine is this URL problem Windows specific?
Yes I think the problem is Windows specific. If I can find out more, I'll let you know.
move to normal priority, pending further action
no further information provided about windows specific behavior; closing due to lack of details
batch transition resolved+wontfix to closed+wontfix
batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen