DO NOT REPLY [Bug 4569] - FOP 0.20.1 : Error while loading TTF fonts for PDF 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=4569

FOP 0.20.1 : Error while loading TTF fonts for PDF rendering

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-11-15 07:46 ---
Right. I've changed the loader code during some refactoring work because it was 
very unclear and too complicated. I still need to fix this in the redesign, 
though.

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

Re: A performance patch for PDFInfo class

[Jeremias Maerki]

Don't be! I think this discussion is very healthy. Thanks to all who
are participating.

On 15 Nov 2002 08:50:19 +1100 Kevin O'Neill wrote:
> ps: Sorry if this is boring anyone :(.


Jeremias Maerki


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

DO NOT REPLY [Bug 2532] - FOP 0.17 does not work with WebSphere V3.5 OS/390

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

FOP 0.17 does not work with WebSphere V3.5 OS/390





--- Additional Comments From [EMAIL PROTECTED]  2002-11-15 07:27 ---
Your're right. Please check bug database, there are some bugs relating to this 
problem. What you must do is to change all the "getBytes" methods in the PDF-
related java source code. Just substitute:
 getBytes();

with

 getBytes("ISO-8859-1");

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

DO NOT REPLY [Bug 3305] - list-block overlapping footnote body

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

list-block overlapping footnote body

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-11-15 03:02 ---
I haven't touched FOP for a while now, but the bug was last seen in this document
which was generated by FOP 0.20.3rc according to document info in acrobat 
reader 4. 

(the fo snipplet is incomplete, so you might need to add something before and
after to make it complete. The rest of the content is confidential, so I can't
send the whole lot.)

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

DO NOT REPLY [Bug 3305] - list-block overlapping footnote body

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

list-block overlapping footnote body





--- Additional Comments From [EMAIL PROTECTED]  2002-11-15 02:58 ---
Created an attachment (id=3850)
the corresponding fo snipplet (incomplete) for the image concerned.

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

DO NOT REPLY [Bug 3305] - list-block overlapping footnote body

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

list-block overlapping footnote body





--- Additional Comments From [EMAIL PROTECTED]  2002-11-15 02:57 ---
Created an attachment (id=3849)
an example page of how the bug looks like

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

DO NOT REPLY [Bug 4569] - FOP 0.20.1 : Error while loading TTF fonts for PDF 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=4569

FOP 0.20.1 : Error while loading TTF fonts for PDF rendering

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 22:37 ---
I'm not sure what class are you talking about, but at least 0.20.5cvs version of
org.apache.fop.fonts.FontFileReader reads file using 2048 bytes buffer. I'll
close the bug, but if you are still experiencing the problem, feel free to
reopen it and provide more detailed explanation.

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

DO NOT REPLY [Bug 4510] - fo:inline common properties ignored?

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

fo:inline common properties ignored?

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 22:21 ---
*** Bug 4269 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 4269] - space-end property is ignored silently in fo:inline

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

space-end property is ignored silently in fo:inline

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 22:21 ---


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

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

DO NOT REPLY [Bug 4316] - Problem of hyphenation in inline-areas

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

Problem of hyphenation in inline-areas

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 22:08 ---
0.20.5cvs, the bug is still there.

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

DO NOT REPLY [Bug 14576] - [PATCH] fsize in FontFileReader is not set

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

[PATCH] fsize in FontFileReader is not set

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|fsize in FontFileReader is  |[PATCH] fsize in
   |not set |FontFileReader is not set

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

DO NOT REPLY [Bug 14576] New: - fsize in FontFileReader is not set

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

fsize in FontFileReader is not set 

   Summary: fsize in FontFileReader is not set
   Product: Fop
   Version: 0.20.4
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


the fsize member is not set to the length of the buffer int the init function.
you cannot read a font file (IOException: file size is 0)

I attach a small patch

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

Re: A performance patch for PDFInfo class

[Kevin O'Neill]

Tom,

> I know I also came in late into this thread. I would like to say I am very
> excited about the possibilities of FOP in the future and the already
> realized gains FOP gives. My overall grasp of FOP at this moment is still
> limited but I have been delving into the code and using it for a current
> project for the past 2 months. In no way am I trying to be insulting to
> anyone. I realize everyone here is very well versed in various areas of
> programming. Performance has always been an interest to me in general so I
> enjoy these types of topics. I don't mind being proven wrong.
> 
> Yes. You are correct on your assumptions based on your code.
> 
> Maybe I should have been more clear and read the initial beginning to this
> thread but I would like to clear two points up, my apologies.
> 
> I was trying to refer to two seperate issues that were being discussed,
> more so to what happens during runtime then compile time.
> 
> The first point was what the String and StringBuffer java code looks in the
> pcode. String does do concantenation with the concat method and
> StringBuffer with append?.
> 
> It does do that except under certain conditions.
> 
> So, what are the conditions under the + operator?
> 
> -If there is a chain of anonymous strings being initialized to a variable a
> LOAD happens.
> -If there is 1 reference to a String at the head or end of a chain of
> anonymous Strings a String.concat happens
> -If there are only 2 references to a String(s) being "concantenated using +
> operator" a String.concat happens
> -If the chain contains 2 or more anonymous strings seperated by at least 1
> reference to a String StringBuffer.append happens
> -If the chain contains 3 or more references to a String(s)
> StringBuffer.append happens
> -If the chain contains at least 2 references to a String(s) and at least 1
> anonymous String StringBuffer.append happens
> 
> What are the conditions for += operator?
> 
> -They are the same as above except for the additional concantenation that
> happens implicitly to the variable adding to itself.

> So to the statement that StringBuffer.append happens in "String addition"
> is only partly true given String.concat happens in a subset of the cases.

Great stuff. I hadn't done tests with two Strings and I think that the
scenarios you provide us with are great.



When I looked at the generated pcode I couldn't understand why there
where so many (any) valueOf operations, so I regenerated the code using
1.4.1, and guess what ... it's very different. Sun have made some
considerable leeps forward in String handling.

Method void concatTests()
   0 ldc #12 
   2 astore_1
   3 new #2 
   6 dup
   7 invokespecial #3 
  10 aload_1
  11 invokevirtual #5 
  14 ldc #13 
  16 invokevirtual #5 
  19 invokevirtual #10 
  22 astore_1
  23 ldc #14 
  25 astore_2
  26 new #2 
  29 dup
  30 invokespecial #3 
  33 ldc #15 
  35 invokevirtual #5 
  38 aload_1
  39 invokevirtual #5 
  42 invokevirtual #10 
  45 astore_3
  46 new #2 
  49 dup
  50 invokespecial #3 
  53 aload_2
  54 invokevirtual #5 
  57 aload_3
  58 invokevirtual #5 
  61 invokevirtual #10 
  64 astore 4
  66 new #2 
  69 dup
  70 invokespecial #3 
  73 aload_1
  74 invokevirtual #5 
  77 aload_2
  78 invokevirtual #5 
  81 aload_3
  82 invokevirtual #5 
  85 invokevirtual #10 
  88 astore 5
  90 new #2 
  93 dup
  94 invokespecial #3 
  97 aload_0
  98 ldc #16 
 100 invokespecial #7 
 103 invokevirtual #5 
 106 aload_0
 107 ldc #13 
 109 invokespecial #7 
 112 invokevirtual #5 
 115 invokevirtual #10 
 118 astore 6
 120 new #2 
 123 dup
 124 invokespecial #3 
 127 ldc #17 
 129 invokevirtual #5 
 132 aload_1
 133 invokevirtual #5 
 136 ldc #18 
 138 invokevirtual #5 
 141 invokevirtual #10 
 144 astore 7
 146 new #2 
 149 dup
 150 invokespecial #3 
 153 aload 4
 155 invokevirtual #5 
 158 aload 5
 160 invokevirtual #5 
 163 aload 6
 165 invokevirtual #5 
 168 invokevirtual #10 
 171 astore 4
 173 new #2 
 176 dup
 177 invokespecial #3 
 180 aload 4
 182 invokevirtual #5 
 185 ldc #19 
 187 invokevirtual #5 
 190 invokevirtual #10 
 193 astore 4
 195 new #2 
 198 dup
 199 invokespecial #3 
 202 aload 4
 204 invokevirtual #5 
 207 ldc #20 
 209 invokevirtual #5 
 212 aload 5
 214 invokevirtual #5 
 217 invokevirtual #10 
 220 astore 4
 222 new #2 
 225 dup
 226 invokespecial #3 
 229 aload 4
 231 invokevirtual #5 
 234 ldc #17 
 236 invokevirtual #5 
 239 aload 5
 241 invokevirtual #5 
 244 ldc #13 
 246 invokevirtual #5 
 249 invokevirtual #10 
 252 astore 4
 254 new #2 
 257 dup
 258 invokespecial #3 
 261 aload_2
 262 invokevirtual #5 
 265 aload_2
 266 invokevirtual #5 
 269 invokevirtual #10 
 272 astore 8
 274 new #2 
 277 dup
 278 invokespecial #3 
 281 aload_2
 282 invokevirtual #5 
 285 aload_3
 286 invokevirtual #5 
 289 ldc #21 
 291 invokevirtual #5 
 294 invokevirtual #10 
 297 astore 9
 299 return

Which goes further to my argument of leaving it to the compiler.

> The point that is more interesting is wh

DO NOT REPLY [Bug 1180] - Problem with monospaced font

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

Problem with monospaced font

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:52 ---
*** Bug 3964 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 3964] - Courier font not displaying/printing correctly

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

Courier font not displaying/printing correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:52 ---


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

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

DO NOT REPLY [Bug 1180] - Problem with monospaced font

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

Problem with monospaced font

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:51 ---
*** Bug 10571 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 10571] - Monospaced Fonts Calculating Incorrect Width

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

Monospaced Fonts Calculating Incorrect Width

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:51 ---


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

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

DO NOT REPLY [Bug 3305] - list-block overlapping footnote body

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

list-block overlapping footnote body

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID
Summary|list-block overlapping  |list-block overlapping
   |footnote body   |footnote body



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:40 ---
Provide an example of the problem, please.

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

DO NOT REPLY [Bug 2964] - problems with height of cells in tables

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

problems with height of cells in tables

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:30 ---
0.20.4 doesn't crash, but the bug is still there.

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

DO NOT REPLY [Bug 2532] - FOP 0.17 does not work with WebSphere V3.5 OS/390

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

FOP 0.17 does not work with WebSphere V3.5 OS/390





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:16 ---
Does anybody still concern about this bug? Could somebody check for example
RenderX XEP under OS/390? It's not clear, is it FOP's bug or some more
fundamental inconsistency.

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

DO NOT REPLY [Bug 1171] - small-caps in static content becomes all-caps

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

small-caps in static content becomes all-caps

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:11 ---
*** Bug 2504 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 2504] - Some font properties in tables are not preserved across columns

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

Some font properties in tables are not preserved across columns

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:11 ---


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

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

DO NOT REPLY [Bug 2460] - Mulitple boder lines between the colums in a table

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

Mulitple boder lines between the colums in a table

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 21:07 ---
Seems to be an obsolete bug, with FOP 0.20.4 table.fo example looks equally to
antenna formatter output.

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

DO NOT REPLY [Bug 2153] - Borders are calculated incorrectly

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

Borders are calculated incorrectly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 20:59 ---
Well, looks like a very unclear bug. Contains a patch to unstated problem... 1.5
years old... Lets close it.

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

RE: forrest DTDs

[Victor Mote]

Keiron Liddle wrote:

> I wouldn't recommend putting the dtd's in our cvs, one version is
> better.

In principle I agree. I think the best solution is for Forrest to make them
available in a small download.

> The are some pages describing the dtd but I presume you mean for
> editing. I think it would be useful to make them downloadable separately
> just for editing.

Yes, I was referring to editing.

> I think the process is something like:
> - put your own catalog in resources/schema/catalog
> - it will then verify with that catalog
> - cocoon will use that catalog when copied across to webapps
>
> Unfortunately it does work like that.
> To get the verification to work I need to add just the local public ID,
> so it uses the forrest one to verify forrest ID's and the local one for
> the local ID.
> Then when it is copied across cocoon can only find the ID for the fop
> dtd and the others are missing.
> If I put all the forrest+fop ID's in the catalog then it cannot verify
> as it cannot find the forrest dtd's relative to the catalog.
>
> So something is a bit broken.

I am not familiar with cocoon, so I am a bit lost. However, the catalog
concept is just for local use -- in other words for a specific
editor/parser. Since Christian has shown us how to find the DTDs on the Web,
we should probably add the URL in the declaration -- then people with
always-on web access can see that one. The catalog is really just for
standalone boxes without access to the URL version, to map the public ID to
a local file. After I downloaded Forrest last night, I was able to add an
entry in XML-Spy to see my local copy of the DTD. Without that mapping, and
since the files don't have the URL, right now an editor will complain that
it can't find the DTD in the current directory.

Victor Mote


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

DO NOT REPLY [Bug 1724] - Text alignment in table cells

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

Text alignment in table cells

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 20:49 ---
Well, "left" and "right" values of text-align work, I believe I can close the bug.

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

DO NOT REPLY [Bug 13325] - [PATCH] build pdfdoc changes

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

[PATCH] build pdfdoc changes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 20:32 ---
Needs to be reworked for Forrest.

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

RE: forrest DTDs

[Victor Mote]

Christian Geisert wrote:

> Hmm .. if  you are working on the documention you'll need forrest anyway
> to render the pages.

I don't really want to render the pages, just work on the content.

> > could suggest to the forrest group that they make these items directly
> > available on their web-site.
>
> http://cvs.apache.org/viewcvs/xml-forrest/src/resources/schema/

Thanks. That is it, sort of -- and now that I know about viewcvs, I'll
probably use it other places. What I am trying to do is to make sure that it
is as easy as possible for any developer to quickly make a change to the
documentation. The link above is a step in that direction.

Victor Mote


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

Re: BASIC-LINK

[Oleg Tkachenko]

Sergio wrote:


and the render crashes...
If I make different the name of the basic-link or the name of the block 
id, the pdf is well rendered.
 
 
I have anothers .fo files with many more links that are well rendered, 
but this file no.
 
Why ?
Looks too bizarre, open a bug in bugzilla and attach full fo document 
illustrating the problem.

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

DO NOT REPLY [Bug 4511] - Underlining not applied to end of hyphenated line

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

Underlining not applied to end of hyphenated line

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 20:11 ---
You right, my mistake.

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

DO NOT REPLY [Bug 7487] - break-before="page" for table inserts empty page

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

break-before="page" for table inserts empty page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 18:59 ---
*** Bug 12650 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 12650] - break-after="page" creates empty page at the end of the 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=12650

break-after="page" creates empty page at the end of the document

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 18:59 ---
Actually this one is duplicate of the bug #7487.

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

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

BASIC-LINK

[Sergio]

Hí again
 
I'm going crazy with this kind of 
problems...
 
I'm rendering a pdf file of 22 pages.
at the first of the file, I have the following 
basic links:
 

tarariiislkjalskjdflksjdflkasjdlfkasjdlfkasjldfkjasldfjl 
basic-link color='#ff' text-decoration='underline' 
internal-destination='subprin3B'>3Bfo:basic-link> 
, color='#ff' text-decoration='underline' 
internal-destination='subprin3D'>3D 
, color='#ff' text-decoration='underline' 
internal-destination='subprin6D'>6D 
, color='#ff' text-decoration='underline' 
internal-destination='subprin6H'>6H>.
-
 
after of this, the rest o the fo file, with some 
blocks

 page n

 page k ...

 
Well, the problem is with the basic link named: 
subprin3D.
 
When fop render the fo file, the only message i get 
is:
[INFO] [11]
[INFO] [12]
[INFO] [13]
-
 
and the render crashes...
If I make different the name of the basic-link or the name of the block id, 
the pdf is well rendered.
 
 
I have anothers .fo files with many more links that are well rendered, but 
this file no.
 
Why ?
 
Thanks at all, Sergio.
 
 
 
 

DO NOT REPLY [Bug 12854] - The path for the font-matrix files is in unix format under windows

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

The path for the font-matrix files is in unix format under windows

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 18:19 ---
Fixed in cvs, will be in the upcoming 0.20.5 + new property fontBaseDir for free.

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

DO NOT REPLY [Bug 13295] - different results using xml or fo (from the same xml-file)

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

different results using xml or fo (from the same xml-file)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 18:14 ---
I believe the difference is because of famous whitespace only text nodes.
Indentation naturally adds more whitespace to a document. Make sure your xslt
processor doesn't indent output fo document.

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

DO NOT REPLY [Bug 4511] - Underlining not applied to end of hyphenated line

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

Underlining not applied to end of hyphenated line





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 18:12 ---
Created an attachment (id=3841)
Example showing underline + hyphenation problem

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

DO NOT REPLY [Bug 4511] - Underlining not applied to end of hyphenated line

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

Underlining not applied to end of hyphenated line

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 18:01 ---
I still have this problem using 0.20.4.  Will attach xsl-fo that produces this
behavior.

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

DO NOT REPLY [Bug 5010] - Better error reporting needed

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

Better error reporting needed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 17:55 ---
*** Bug 6539 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 6539] - Poor error recovery from invalid FO; wrong exit status

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

Poor error recovery from invalid FO; wrong exit status

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 17:55 ---
System.exit stuff fixed already and the rest is a dublicate of the bug #5010.

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

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

DO NOT REPLY [Bug 2107] - indentation in "em" units is larger than the letter "m"

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

indentation in "em" units is larger than the letter "m"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 17:48 ---
em unit is not a width of 'M' letter! em unit is defined as current font-size
and font-size is defined as "em square", which in turn defined in CSS as "an
abstract square whose height is the intended distance between lines of type in
the same type size"[1].

[1] http://www.w3.org/TR/REC-CSS2/fonts.html#em-square

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

DO NOT REPLY [Bug 4511] - Underlining not applied to end of hyphenated line

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

Underlining not applied to end of hyphenated line

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 17:09 ---
Works fine in 0.20.4.

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

cvs commit: xml-fop forrest.properties

[chrisg]

chrisg  2002/11/14 09:04:48

  Modified:.forrest.properties
  Log:
  Exclude compliance.xml from validation
  (This is a quick fix as Forrest is configured to validate all docs and fails
  if an error occurs. The goal is of course to validate compliance.xml)
  
  Revision  ChangesPath
  1.2   +2 -0  xml-fop/forrest.properties
  
  Index: forrest.properties
  ===
  RCS file: /home/cvs/xml-fop/forrest.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- forrest.properties28 Oct 2002 08:40:59 -  1.1
  +++ forrest.properties14 Nov 2002 17:04:47 -  1.2
  @@ -25,3 +25,5 @@
   #project.lib-dir=${project.content-dir}/lib
   #project.classes-dir=${project.content-dir}/classes
   
  +forrest.validate.xdocs.excludes=compliance.xml
  +
  
  
  

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

DO NOT REPLY [Bug 7903] - org.apache.fop.apps.Version.getVersion()

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

org.apache.fop.apps.Version.getVersion()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 16:58 ---
Looks like invalid. But Jonathan, feel free to reopen the bug.

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

Re: footnote

[Oleg Tkachenko]

Sergio wrote:


I'm trying to put a footnote at the same height that a static-content which draw a page number, but i can't do that.

You cannot do it in a reasonably robust way. Footnotes are rendered within a 
footnote-reference-area, which is a subregion of region-body and your static 
content is rendered within region-after. There is no way in xsl 1.0 to 
synchronoze areas in different regions.
Actually as a dirty hack you can overlap region-body and region-after:


and this way region-after will be rendered over region-body (or vice versa) so 
it might looks like footnote and page number are on the same line.

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

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

[keiron]

keiron  2002/11/14 07:22:30

  Modified:src/org/apache/fop/render/pdf PDFXMLHandler.java
  Log:
  make sure it has valid pdf context
  
  Revision  ChangesPath
  1.11  +4 -1  xml-fop/src/org/apache/fop/render/pdf/PDFXMLHandler.java
  
  Index: PDFXMLHandler.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/PDFXMLHandler.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- PDFXMLHandler.java11 Nov 2002 08:50:53 -  1.10
  +++ PDFXMLHandler.java14 Nov 2002 15:22:30 -  1.11
  @@ -264,6 +264,9 @@
   + PDFNumber.doubleOut(vals[5]) + " cm\n");
   }
   
  +if (pdfInfo.pdfContext == null) {
  +pdfInfo.pdfContext = pdfInfo.pdfPage;
  +}
   PDFGraphics2D graphics = new PDFGraphics2D(true, pdfInfo.fi, 
pdfInfo.pdfDoc,
pdfInfo.pdfContext, 
pdfInfo.pdfPage.referencePDF(),
pdfInfo.currentFontName,
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/image/analyser SVGReader.java

[keiron]

keiron  2002/11/14 07:19:42

  Modified:src/org/apache/fop/image AbstractFopImage.java BmpImage.java
EPSImage.java FopImage.java FopImageConsumer.java
GifImage.java ImageCache.java ImageFactory.java
JAIImage.java JimiImage.java JpegImage.java
   src/org/apache/fop/image/analyser SVGReader.java
  Log:
  some cleanup of comments and code
  
  Revision  ChangesPath
  1.15  +77 -34xml-fop/src/org/apache/fop/image/AbstractFopImage.java
  
  Index: AbstractFopImage.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/AbstractFopImage.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- AbstractFopImage.java 8 Nov 2002 10:47:58 -   1.14
  +++ AbstractFopImage.java 14 Nov 2002 15:19:41 -  1.15
  @@ -1,6 +1,6 @@
   /*
* $Id$
  - * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
  + * Copyright (C) 2001-2002 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
  @@ -8,15 +8,12 @@
   package org.apache.fop.image;
   
   // Java
  -import java.net.URL;
   import java.awt.color.ColorSpace;
   import java.awt.color.ICC_Profile;
   import java.io.InputStream;
   
   // FOP
   import org.apache.fop.pdf.PDFColor;
  -import org.apache.fop.image.analyser.ImageReaderFactory;
  -import org.apache.fop.image.analyser.ImageReader;
   import org.apache.fop.fo.FOUserAgent;
   
   /**
  @@ -26,17 +23,20 @@
* @see FopImage
*/
   public abstract class AbstractFopImage implements FopImage {
  +/**
  + * Keeps track of what has been loaded.
  + */
   protected int loaded = 0;
   
   /**
* Image width (in pixel).
*/
  -protected int m_width = 0;
  +protected int width = 0;
   
   /**
* Image height (in pixel).
*/
  -protected int m_height = 0;
  +protected int height = 0;
   
   /**
* Image input stream.
  @@ -51,32 +51,32 @@
   /**
* Image color space (java.awt.color.ColorSpace).
*/
  -protected ColorSpace m_colorSpace = null;
  +protected ColorSpace colorSpace = null;
   
   /**
* Bits per pixel.
*/
  -protected int m_bitsPerPixel = 0;
  +protected int bitsPerPixel = 0;
   
   /**
* Image data (uncompressed).
*/
  -protected byte[] m_bitmaps = null;
  +protected byte[] bitmaps = null;
   
   /**
* Image data size.
*/
  -protected int m_bitmapsSize = 0;
  +protected int bitmapsSize = 0;
   
   /**
* Image transparency.
*/
  -protected boolean m_isTransparent = false;
  +protected boolean isTransparent = false;
   
   /**
* Transparent color (org.apache.fop.pdf.PDFColor).
*/
  -protected PDFColor m_transparentColor = null;
  +protected PDFColor transparentColor = null;
   
   /**
* Constructor.
  @@ -86,63 +86,94 @@
* image height
* 
* The image data isn't kept in memory.
  - * @param input input stream
  - * imgReader ImageReader object
  - * @return a new FopImage object
  + * @param info image information
*/
   public AbstractFopImage(FopImage.ImageInfo info) {
   this.inputStream = info.inputStream;
   this.imageInfo = info;
  -if(this.imageInfo.width != -1) {
  -m_width = imageInfo.width;
  -m_height = imageInfo.height;
  +if (this.imageInfo.width != -1) {
  +width = imageInfo.width;
  +height = imageInfo.height;
   loaded = loaded | DIMENSIONS;
   }
   }
   
  +/**
  + * Get the mime type for this image.
  + *
  + * @return the mime type for the image
  + */
   public String getMimeType() {
   return imageInfo.mimeType;
   }
   
   /**
* Load image data and initialize its properties.
  + *
  + * @param type the type of loading to do
  + * @param ua the user agent for handling logging etc.
  + * @return true if the loading was successful
*/
   public synchronized boolean load(int type, FOUserAgent ua) {
  -if((loaded & type) != 0) {
  +if ((loaded & type) != 0) {
   return true;
   }
   boolean success = true;
  -if(((type & DIMENSIONS) != 0) && ((loaded & DIMENSIONS) == 0)) {
  +if (((type & DIMENSIONS) != 0) && ((loaded & DIMENSIONS) == 0)) {
   success = success && loadDimensions(ua);
   
  -if(!success) {
  +if (!success) {
   return false;
   }
   loaded = loaded | DIMENSIONS;
   }
  -if(((type & BITMA

Re: Announcement: XSL-FO Reporting Tool

[Oleg Tkachenko]

Keiron Liddle wrote:


>Well one more commercial tool powered by FOP. What about creating a page on
>the website, hmmm, "FOP-powered tools" or "FOP in a real world" or something
>like this?


Go ahead.
There are plenty of those types of pages for other projects (forrest,
cocoon etc.)


Ok, I will collect data and then I'll try to create such a page. btw, it's a 
chance to grasp forrest.

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

DO NOT REPLY [Bug 14529] - SVG url references do not work

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

SVG url references do not work





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 14:40 ---
Related thread: http://nagoya.apache.org/eyebrowse/BrowseList?listName=fop-
[EMAIL PROTECTED]&by=thread&from=274313

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

Re: A performance patch for PDFInfo class

[TSereme]

   
 
  "Kevin O'Neill"  
 
  
  com.au>  cc:   (bcc: Thomas 
Seremet/GCR-NAmerica/GRN) 
   Subject:  Re: A performance patch for 
PDFInfo class  
  11/13/2002 05:41 
 
  AM   
 
  Please respond to
 
  fop-dev  
 
   
 
   
 









>
>
>> Some more insight or confusion. The byte code maybe similar in the sense
>> that String uses "".concat() and
>> StringBuffer uses new StringBuffer().append to do their individual
>> concatenations but the way they are
>> treated by the JVM is not the same. Of course not all JVM's are created
>> equal but Strings are stored as constants thus you see the ldc opcode
when
>> creating Strings. Even though a String holds on to an internal
>> character array as does a StringBuffer, a String creates a new String
when
>> it is concatentating another String to itself NOT modifing its internal
>> character array. On the other hand a StringBuffer actually modifies its
>> internal character array to represent the new String though this is
>> accomplished by increasing the array size by creating a new char array.
>> This is only part of the story since there is a difference between
Strings
>> stored in the so-called constants pool and new Strings created during
>> runtime which do not go into the constants-pool automatically. Very good
>> info concerning this on the web.
>
>Okay firstly, please look at the pcode generated earlier in this thread.
>It was generated by the moder compiler on jdk 1.4.0 the string addition
>is indeed concatinated using StringBuffer.append()
>
>public String testStringBufferChained()
>{
>return (new StringBuffer().append("this ")
>.append(makeString("is "))
>.append("a ")
>.append(makeString("test"))).toString();
>}
>
>public String testStringAdd()
>{
>return
>"this "
>+ makeString("is ")
>+ "a "
>+ makeString("test");
>}
>
>becomes ...
>
>Method java.lang.String testStringBufferChained()
>   0 new #2 
>   3 dup
>   4 invokespecial #3 
>   7 ldc #4 
>   9 invokevirtual #5 append(java.lang.String)>
>  12 aload_0
>  13 ldc #6 
>  15 invokespecial #7 makeString(java.lang.String)>
>  18 invokevirtual #5 append(java.lang.String)>
>  21 ldc #8 
>  23 invokevirtual #5 append(java.lang.String)>
>  26 aload_0
>  27 ldc #9 
>  29 invokespecial #7 makeString(java.lang.String)>
>  32 invokevirtual #5 append(java.lang.String)>
>  35 invokevirtual #10 
>  38 areturn
>
>Method java.lang.String testStringAdd()
>   0 new #2 
>   3 dup
>   4 invokespecial #3 
>   7 ldc #4 
>   9 invokevirtual #5 append(java.lang.String)>
>  12 aload_0
>  13 ldc #6 
>  15 invokespecial #7 makeString(java.lang.String)>
>  18 invokevirtual #5 append(java.lang.String)>
>  21 ldc #8 
>  23 invokevirtual #5 append(java.lang.String)>
>  26 aload_0
>  27 ldc #9 
>  29 invokespecial #7 makeString(java.lang.String)>
>  32 invokevirtual #5 append(java.lang.String)>
>  35 invokevirtual #10 
>  38 areturn
>
>
>So once again I say these are these are identical, the underlying VM has
>no idea of any difference. I would though contend that the String
>addition is easier to read.

I know I also came in late into this thread. I would like to say I am very
excited about the possibilities of FOP in the future and the already
realized gains FOP gives. My overall grasp of FOP at this moment is still
limited but I have been delving into the code and using it for a current
project for the past 2 months. In no way am I trying to be insulting to
anyone. I realize everyone here is very well versed in various areas of
programming. Performance has always been an interest to me in general so I
enjoy these types of topics. I don't mind being proven wrong.

Yes. You are correct on your assumptions based on your cod

footnote

[Sergio]

Hello again...
 
I'm trying to put a footnote at the same height 
that a static-content which draw a page number, but i can't do 
that.
 
static-content
Página 

 
footnote

    (*)
    

        
        
    (*) Datos 
actualizados a 2002
        

    


 
now:
 (*) 
Datos actualizados a 2002
 
        
                
    
   
                
                
                
                
                
                
            Página 
1
 
i want

        
                
    

    (*) Datos actualizados a 
2002    
Página 1
 
 

 
 
Can you help 
me?
 
thx, Sergio.

cvs commit: xml-fop/src/org/apache/fop/area/inline Anchor.java Character.java Container.java FilledArea.java Image.java InlineArea.java InlineParent.java Leader.java Viewport.java Word.java

[keiron]

keiron  2002/11/14 03:13:33

  Modified:src/org/apache/fop/area Area.java AreaTree.java
BlockParent.java CachedRenderPagesModel.java
LineArea.java Page.java PageViewport.java
RegionReference.java RegionViewport.java Span.java
Title.java Trait.java
   src/org/apache/fop/area/inline Anchor.java Character.java
Container.java FilledArea.java Image.java
InlineArea.java InlineParent.java Leader.java
Viewport.java Word.java
  Log:
  a bit of a cleanup of collections and comments
  
  Revision  ChangesPath
  1.13  +3 -2  xml-fop/src/org/apache/fop/area/Area.java
  
  Index: Area.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/Area.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Area.java 6 Nov 2002 15:07:04 -   1.12
  +++ Area.java 14 Nov 2002 11:13:32 -  1.13
  @@ -9,6 +9,7 @@
   
   import java.io.Serializable;
   
  +import java.util.Map;
   import java.util.HashMap;
   
   // If the area appears more than once in the output
  @@ -187,7 +188,7 @@
*
* @return the map of traits
*/
  -public HashMap getTraits() {
  +public Map getTraits() {
   return this.props;
   }
   
  
  
  
  1.12  +21 -19xml-fop/src/org/apache/fop/area/AreaTree.java
  
  Index: AreaTree.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/AreaTree.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- AreaTree.java 3 Nov 2002 16:24:21 -   1.11
  +++ AreaTree.java 14 Nov 2002 11:13:32 -  1.12
  @@ -11,7 +11,9 @@
   
   import java.util.ArrayList;
   import java.util.List;
  +import java.util.Map;
   import java.util.HashMap;
  +import java.util.Set;
   import java.util.HashSet;
   import java.util.Iterator;
   
  @@ -38,10 +40,10 @@
   private AreaTreeModel model;
   
   // hashmap of arraylists containing pages with id area
  -private HashMap idLocations = new HashMap();
  +private Map idLocations = new HashMap();
   // list of id's yet to be resolved and arraylists of pages
  -private HashMap resolve = new HashMap();
  -private ArrayList treeExtensions = new ArrayList();
  +private Map resolve = new HashMap();
  +private List treeExtensions = new ArrayList();
   
   /**
* Create a render pages area tree model.
  @@ -100,7 +102,7 @@
   }
   list.add(pv);
   
  -HashSet todo = (HashSet)resolve.get(id);
  +Set todo = (Set)resolve.get(id);
   if (todo != null) {
   for (Iterator iter = todo.iterator(); iter.hasNext();) {
   Resolveable res = (Resolveable)iter.next();
  @@ -125,7 +127,7 @@
* @param res the Resolveable object to resolve
*/
   public void addUnresolvedID(String id, Resolveable res) {
  -HashSet todo = (HashSet)resolve.get(id);
  +Set todo = (Set)resolve.get(id);
   if (todo == null) {
   todo = new HashSet();
   resolve.put(id, todo);
  @@ -146,9 +148,9 @@
   String[] ids = res.getIDs();
   for (int count = 0; count < ids.length; count++) {
   if (idLocations.containsKey(ids[count])) {
  -res.resolve(ids[count], (ArrayList)idLocations.get(ids[count]));
  +res.resolve(ids[count], (List)idLocations.get(ids[count]));
   } else {
  -HashSet todo = (HashSet)resolve.get(ids[count]);
  +Set todo = (Set)resolve.get(ids[count]);
   if (todo == null) {
   todo = new HashSet();
   resolve.put(ids[count], todo);
  @@ -180,7 +182,7 @@
   public void endDocument() {
   for (Iterator iter = resolve.keySet().iterator(); iter.hasNext();) {
   String id = (String)iter.next();
  -HashSet list = (HashSet)resolve.get(id);
  +Set list = (Set)resolve.get(id);
   for (Iterator resIter = list.iterator(); resIter.hasNext();) {
   Resolveable res = (Resolveable)resIter.next();
   if (!res.isResolved()) {
  @@ -228,10 +230,10 @@
* The pages are stored and can be retrieved in any order.
*/
   public static class StorePagesModel extends AreaTreeModel {
  -private ArrayList pageSequence = null;
  -private ArrayList titles = new ArrayList();
  -private ArrayList currSequence;
  -private ArrayList extensions = new ArrayList();
  +private List pageSequence = null;
  +private List titles = new ArrayList();
  

RE: [PATCH] XSL-FO Compliance Document

[Keiron Liddle]

On Wed, 2002-11-13 at 17:39, Victor Mote wrote:
> The purpose of the 13325 patch was to get the pdf generation working again.
> Christian tried to apply it, but said that he got errors. I reviewed it,
> couldn't see anything obviously wrong with it. However, I am not sure what
> the nature of the errors were either -- it needs to be applied to the trunk,
> but you must use a build off of the maintenance branch to build the doc. It
> may also very well be pointed to documents that don't exist anymore, as it
> seems like you have changed the directory structure some. Please let me know
> if I need to rework it. Also, it was not a perfect implementation, but
> rather a step in the right direction. I hope to get a couple more passes at
> it before 0.20.5 is released.

Unfortunately that patch doesn't really apply anymore.
It may be able to work in a similar way but it needs to go through
forrest+cocoon to get the sitemap conversions and other things.
We will need a xslt that does documents to document conversion by
loading the documents from the book.xml files.

So yes it will need reworking, this will need some forrest knowledge but
a documents2document stylesheet would be a good start.

Keiron


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

Re: forrest DTDs

[Keiron Liddle]

Hi Victor,

I wouldn't recommend putting the dtd's in our cvs, one version is
better.
The are some pages describing the dtd but I presume you mean for
editing. I think it would be useful to make them downloadable separately
just for editing.
You still need forrest to do the verifying and generation.


It seems I spoke too soon about verifying.

I think the process is something like:
- put your own catalog in resources/schema/catalog
- it will then verify with that catalog
- cocoon will use that catalog when copied across to webapps

Unfortunately it does work like that.
To get the verification to work I need to add just the local public ID,
so it uses the forrest one to verify forrest ID's and the local one for
the local ID.
Then when it is copied across cocoon can only find the ID for the fop
dtd and the others are missing.
If I put all the forrest+fop ID's in the catalog then it cannot verify
as it cannot find the forrest dtd's relative to the catalog.

So something is a bit broken.

Keiron.

On Thu, 2002-11-14 at 10:19, Victor Mote wrote:
> Keiron:
> 
> It looks like most of the documents in src/documentation/contents/xdocs use
> Public IDs for their DTD declarations. The forrest web site indicates that
> it has a catalog that maps these Public IDs. However, it looks like one has
> to download forrest to get either the catalog or the DTDs. Do you think it
> worthwhile to include the catalog & DTDs in the FOP cvs (perhaps in
> resources/schema/dtd/forrest ??) so that developers can get to them without
> needing to download forrest? Alternatively (or perhaps in addition), we
> could suggest to the forrest group that they make these items directly
> available on their web-site.
> 
> Victor Mote



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

Re: forrest DTDs

[Christian Geisert]

Victor Mote wrote:

Keiron:

It looks like most of the documents in src/documentation/contents/xdocs use
Public IDs for their DTD declarations. The forrest web site indicates that
it has a catalog that maps these Public IDs. However, it looks like one has
to download forrest to get either the catalog or the DTDs. Do you think it
worthwhile to include the catalog & DTDs in the FOP cvs (perhaps in
resources/schema/dtd/forrest ??) so that developers can get to them without
needing to download forrest? Alternatively (or perhaps in addition), we


Hmm .. if  you are working on the documention you'll need forrest anyway
to render the pages.


could suggest to the forrest group that they make these items directly
available on their web-site.


http://cvs.apache.org/viewcvs/xml-forrest/src/resources/schema/

Christian


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

Re: Announcement: XSL-FO Reporting Tool

[Christian Geisert]

Oleg Tkachenko wrote:

[..]


Well one more commercial tool powered by FOP. What about creating a page 
on the website, hmmm, "FOP-powered tools" or "FOP in a real world" or 
something like this?

+1

I've been asked a few times if FOP is production-ready.

Christian


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

forrest DTDs

[Victor Mote]

Keiron:

It looks like most of the documents in src/documentation/contents/xdocs use
Public IDs for their DTD declarations. The forrest web site indicates that
it has a catalog that maps these Public IDs. However, it looks like one has
to download forrest to get either the catalog or the DTDs. Do you think it
worthwhile to include the catalog & DTDs in the FOP cvs (perhaps in
resources/schema/dtd/forrest ??) so that developers can get to them without
needing to download forrest? Alternatively (or perhaps in addition), we
could suggest to the forrest group that they make these items directly
available on their web-site.

Victor Mote


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

DO NOT REPLY [Bug 14489] - [PATCH] small workaround for outputHeader called two times

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

[PATCH] small workaround for outputHeader called two times





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 09:15 ---
I have created BUG 14539 for Xalan 
see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14539

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