white-space line-ending changes
I have committed some changes to the trunk that clean up 1) tabs, 2) spaces at end of lines, and 3) CR/LF line endings. These touched quite a few files, mostly doc, but should have no effect other than to minimize future spurious deltas. I do not see the auto mail messages coming from CVS related to these changes -- perhaps it is smart enough to know that these are innocuous, or perhaps there is something wrong with my mail account. At any rate, I wanted you to know what was going on when you see the files being updated. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: white-space line-ending changes
Victor Mote wrote: I have committed some changes to the trunk that clean up 1) tabs, 2) spaces at end of lines, and 3) CR/LF line endings. These touched quite a few files, mostly doc, but should have no effect other than to minimize future spurious deltas. I do not see the auto mail messages coming from CVS related to these changes -- perhaps it is smart enough to know that these are innocuous, or perhaps there is something wrong with my mail account. I had the same problem when I commited for the first time. As far as I found out, you have to be subscribed to fop-cvs mail list using your *apache email address* + first message may be postponed a little bit by moderator (nobody knows who is it though :). -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 2987] - Large graphics put FOP 0.19 into an infinite loop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2987. 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=2987 Large graphics put FOP 0.19 into an infinite loop [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-30 20:44 --- The patch supplied to resolve bug 8778 resolves this bug as well, halting the infinite loop after a sufficiently large number of attempts at layout. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14456] - Attribute causes infinite loop.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14456. 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=14456 Attribute causes infinite loop. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-30 20:49 --- Patch for bug #8778 terminates the loop of the bad file while still permitting processing of good file. The fix only prevents loop termination- it does not resolve the issues of the document's constraints and layout, which are issues that will be addressed in further versions of FOP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12262] - Lacking detection of endless loops
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12262. 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=12262 Lacking detection of endless loops --- Additional Comments From [EMAIL PROTECTED] 2002-11-30 20:51 --- The fix for bug #8778 should aid with this issue, though without real testing, that's only speculation. Thus far, it has caused loop termination in the other infinite looping bugs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Another font-related issue: TTF ascender values
Hi everyone, Has anyone else noticed that the ascender values calculated for some TrueType fonts by the TTFReader seem to be very large? I have found this at least for the MS versions of Arial. It makes it look like there is a lot of leading (line-height) when there is not. In TTFFile.java, in the method readHorizontalHeader (used to read the hhea table, there is the following comment. ascender = in.readTTFShort();// Use sTypoAscender in OS/2 table? In fact, the ascender values in the OS/2 table are smaller. In the OpenType specification, it says that the hhea values are Macintosh-specific. The commentary seems to indicate that the OS/2 values are closer to representing the actual font characteristics. At least for Arial, I certainly prefer the smaller values, but I haven't used other TTF fonts. Any opinions on this? If we make the change, it will change calculated font values and therefore have an effect on layout. Regards, Karen Lease - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow Block.java
klease 2002/11/30 14:50:14
Modified:src/org/apache/fop/fo/flow Tag: fop-0_20_2-maintain
Block.java
Log:
Fix a small bug in the infinite loop prevention logic
Revision ChangesPath
No revision
No revision
1.41.2.13 +2 -1 xml-fop/src/org/apache/fop/fo/flow/Block.java
Index: Block.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Block.java,v
retrieving revision 1.41.2.12
retrieving revision 1.41.2.13
diff -u -r1.41.2.12 -r1.41.2.13
--- Block.java28 Nov 2002 15:23:23 - 1.41.2.12
+++ Block.java30 Nov 2002 22:50:14 - 1.41.2.13
@@ -96,6 +96,7 @@
}
if (this.marker == START) {
+noLayoutCount=0; // Reset the loop counter.
// Common Accessibility Properties
AccessibilityProps mAccProps = propMgr.getAccessibilityProps();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
