cvs commit: xml-fop/src/documentation/content/xdocs anttask.xml bugs.xml compiling.xml compliance.xml configuration.xml download.xml embedding.xml examples.xml extensions.xml faq.xml fo.xml fonts.xml gethelp.xml graphics.xml hyphenation.xml index.xml license.xml logocontest.xml maillist.xml news.xml output.xml pdfencryption.xml relnotes.xml resources.xml running.xml servlets.xml status.xml tabs.xml team.xml
vmote 2003/11/12 07:12:00 Modified:src/documentation/content/xdocs anttask.xml bugs.xml compiling.xml compliance.xml configuration.xml download.xml embedding.xml examples.xml extensions.xml faq.xml fo.xml fonts.xml gethelp.xml graphics.xml hyphenation.xml index.xml license.xml logocontest.xml maillist.xml news.xml output.xml pdfencryption.xml relnotes.xml resources.xml running.xml servlets.xml status.xml tabs.xml team.xml Log: update URLs for DTDs Revision ChangesPath 1.8 +2 -2 xml-fop/src/documentation/content/xdocs/anttask.xml Index: anttask.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/anttask.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- anttask.xml 17 Oct 2003 22:21:53 - 1.7 +++ anttask.xml 12 Nov 2003 15:11:59 - 1.8 @@ -1,6 +1,6 @@ ?xml version=1.0 standalone=no? !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN - http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd; + http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd; document header 1.7 +2 -2 xml-fop/src/documentation/content/xdocs/bugs.xml Index: bugs.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/bugs.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- bugs.xml 15 Sep 2003 20:54:01 - 1.6 +++ bugs.xml 12 Nov 2003 15:11:59 - 1.7 @@ -1,6 +1,6 @@ ?xml version=1.0 standalone=no? !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN - http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd; + http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd; document header 1.11 +2 -2 xml-fop/src/documentation/content/xdocs/compiling.xml Index: compiling.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/compiling.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- compiling.xml 16 Oct 2003 15:06:33 - 1.10 +++ compiling.xml 12 Nov 2003 15:11:59 - 1.11 @@ -1,6 +1,6 @@ ?xml version=1.0 standalone=no? !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN - http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd; + http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd; document header 1.24 +1 -1 xml-fop/src/documentation/content/xdocs/compliance.xml Index: compliance.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/compliance.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- compliance.xml15 Sep 2003 20:54:01 - 1.23 +++ compliance.xml12 Nov 2003 15:11:59 - 1.24 @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8? !DOCTYPE compliance PUBLIC -//APACHE//DTD Compliance V1.0//EN - http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/documentation/resources/schema/dtd/compliance-v10.dtd?rev=1.6; + http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/documentation/resources/schema/dtd/compliance-v10.dtd; compliance head 1.16 +2 -2 xml-fop/src/documentation/content/xdocs/configuration.xml Index: configuration.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/configuration.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- configuration.xml 15 Sep 2003 20:54:01 - 1.15 +++ configuration.xml 12 Nov 2003 15:11:59 - 1.16 @@ -1,6 +1,6 @@ ?xml version=1.0 standalone=no? !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN - http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd; + http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/context/resources/schema/dtd/document-v12.dtd; document header 1.14 +2 -2 xml-fop/src/documentation/content/xdocs/download.xml Index: download.xml
cvs commit: xml-fop/src/documentation/content/xdocs resources.xml
vmote 2003/11/12 07:29:59 Modified:src/documentation/content/xdocs resources.xml Log: add link for UTR-14 Revision ChangesPath 1.32 +7 -1 xml-fop/src/documentation/content/xdocs/resources.xml Index: resources.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/resources.xml,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- resources.xml 12 Nov 2003 15:11:59 - 1.31 +++ resources.xml 12 Nov 2003 15:29:59 - 1.32 @@ -46,6 +46,12 @@ /li /ul /section + section id=specs-unicode +titleUnicode/title +ul + lijump href=http://www.unicode.org/reports/tr14;UTR-14 (Unicode Standard Annex #14: Line Breaking Properties)/jump/li +/ul + /section section id=specs-other titleOther/title ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TextLayoutManager.java
J.Pietschmann wrote: [EMAIL PROTECTED] wrote: Hyphenation problem in Bug 23985 Actually, implementing UTR14 would solve the line breaking problem, although not the URL breaking problem. Points to discuss: ... - Should we provide for custom line breaking algorithms? Some languages/scripts like Thai almost certainly require augmenting any stock line breaking algorithms. However, the problem seems to be more clever breaking of non-natural-languaage stuff, like URL. We can leave this completely to the FO creators, forcing them for example + use language=x-url to turn off hyphenation locally + use glue characters line NBZWS to keep the stock line breaking algorithm to break after slashes The latter is quite intrusive. IMO, yes, we should allow for custom line-breaking, although it somewhat depends on what level you are thinking. IIRC, this is the example used for the GoF Strategy pattern. Now, we have now implemented in a simplistic (and, so far, not very useful) way, the layout strategy concept. Any given layout strategy can control how its line-breaking works. It could conceivably use one of several stock strategies available, its own proprietary method, or even allow the user to choose. In general, I hope that proprietary methods can/will be extracted to stock strategies for others to use, but I suppose that may not always be feasible. I know of at least two line-breaking strategies that we probably want to have in our stock strategies: 1) the line-by-line method used right now, and 2) a Tex-like paragraph-oriented strategy, which AFAIK doesn't exist yet. In your URL example, couldn't FOP see the x-url language automatically add or assume the glue characters for the user? That would perhaps make it less obtrusive (I assume that you meant for the user). I've got my own UTR14 implementation (simplified, of course), which should appear on http://cvs.apache.org/~pietsch later this evening for review. It uses a LineBreakStatus object for tracking the status, which might be folded into the LayoutContext or a subclass used for inline FOs and text. Comments? I don't see it there yet, but I am a little confused. It seems to me that line-breaking consists of at least these components: 1) character-based line-breaking opportunities (which UTR14 addresses), 2) word-based line-breaking opportunities (which hyphenation dictionaries and patterns address), and 3) some strategy for using these to find acceptable/optimal line breaks. It sounds like you have addressed at least 1 and 3 in your implementation. If the part related to item 1 is factored out for use/reuse, that sure seems valuable. Then the part related to item 3 becomes (perhaps) one of the line-breaking strategies available to layout strategies? Or maybe I have underestimated the scope of UTR14? This seems at least remotely related to fo.FOText.isWordChar(), which attempts to find breaks between words. Victor Mote
CVS (src bin) zip'd up for nightlies?
Is it possible we could implement a system to get the CVS nightlies (src /or bin) for fop-1.0Dev zipped and/or tar'd for simple downloading and available from the Dev tab? Having to log in with CVS access is kind of a pain, and I don't know of another way to download the stuff. It might also be nice to have at least a most current (assuming there've been bugfixes ;-p) for the 0.20.5 version as well. Web Maestro Clay
FOP logo update
I was unable to make much progress on this topic. I am unable to get SVG and/or vector versions of the logo. We do, however, have a JPG version. -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com/ PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Whole Web Site PDF update
FWIW, I'm still planning on making updates on this front. However, it's taken more time than I planned getting familiar with Forrest. -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com/ PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
cvs commit: xml-fop/src/documentation/content/xdocs faq.xml fo.xml
vmote 2003/11/12 09:28:07
Modified:src/documentation/content/xdocs faq.xml fo.xml
Log:
add doc for using current date and time, and create an FAQ referencing it
Revision ChangesPath
1.40 +6 -0 xml-fop/src/documentation/content/xdocs/faq.xml
Index: faq.xml
===
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/faq.xml,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- faq.xml 12 Nov 2003 15:11:59 - 1.39
+++ faq.xml 12 Nov 2003 17:28:07 - 1.40
@@ -972,6 +972,12 @@
/p
/answer
/faq
+faq id=xslt-current-date
+ question(XSLT) How can I use the current date and time in my
document?/question
+ answer
+pSee link href=fo.html#xslt-dateCurrent Date and Time/link./p
+ /answer
+/faq
/part
part id=part-help
titleGeneral suggestions. How to solve problems./title
1.9 +22 -1 xml-fop/src/documentation/content/xdocs/fo.xml
Index: fo.xml
===
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/fo.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- fo.xml12 Nov 2003 15:11:59 - 1.8
+++ fo.xml12 Nov 2003 17:28:07 - 1.9
@@ -82,6 +82,27 @@
/p
/section
/section
+section id=xslt
+ titleXSLT Issues/title
+ section id=xslt-date
+titleCurrent Date and Time/title
+pXSL-FO does not currently have a function for retrieving the current
date and time.
+However, in some cases, XSLT can be used to place the current date and time into
the XSL-FO document as it is generated./p
+pOne possibility is to use the link
href=http://exslt.org/date/index.html;exslt date and time extension/link./p
+pAnother possibility is to use java or javascript (or perhaps some other
language).
+Here is an example, using java, that works with Xalan. First, create the
appropriate namespace:/p
+source![CDATA[xsl:stylesheet version=1.0
+ ...
+ xmlns:java=http://xml.apache.org/xslt/java; exclude-result-prefixes=java
+ ...]]/source
+pNext, use the java language to retrieve and format the current date and
time.
+Here is an example template:/p
+source![CDATA[xsl:template match=TodaysDate
+xsl:value-of select=java:format(java:java.text.SimpleDateFormat.new
+(' d, , h:mm:ss a (zz)'), java:java.util.Date.new())/
+ /xsl:template]]/source
+ /section
+/section
section id=xsl-fo
titleXSL-FO Issues/title
section id=fo-center-vertical
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs fo.xml
vmote 2003/11/12 09:41:06 Modified:src/documentation/content/xdocs fo.xml Log: make external site a jump instead of link Revision ChangesPath 1.10 +2 -2 xml-fop/src/documentation/content/xdocs/fo.xml Index: fo.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/fo.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- fo.xml12 Nov 2003 17:28:07 - 1.9 +++ fo.xml12 Nov 2003 17:41:06 - 1.10 @@ -88,7 +88,7 @@ titleCurrent Date and Time/title pXSL-FO does not currently have a function for retrieving the current date and time. However, in some cases, XSLT can be used to place the current date and time into the XSL-FO document as it is generated./p -pOne possibility is to use the link href=http://exslt.org/date/index.html;exslt date and time extension/link./p +pOne possibility is to use the jump href=http://exslt.org/date/index.html;exslt date and time extension/jump./p pAnother possibility is to use java or javascript (or perhaps some other language). Here is an example, using java, that works with Xalan. First, create the appropriate namespace:/p source![CDATA[xsl:stylesheet version=1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP logo update
Clay Leeds wrote: I was unable to make much progress on this topic. I am unable to get SVG and/or vector versions of the logo. We do, however, have a JPG version. Thanks for your efforts here. I'll work on creating an svg version. Victor Mote
RE: Setup code in Driver
Jeremias Maerki wrote: I'm not in a fighter mood today so please change getContentHandler() to something other than public, make sure you check the test cases regularly, adjust the example code to the new API and keep in mind that Cocooners will want to migrate their FOPSerializer some day (They use getContentHandler() at the moment). I am not sure whether this is all a problem I caused or not. The changes I made were *supposed* to be in-place (which made them awkward) and not cause API problems, but sometimes that works differently in theory than in practice. AFAIK, we *must* rely on timely user testing to find these problems. If we have test cases that need to be run, then we need to document that process. The last comments I remember (from Keiron, IIRC) were that testing was hopelessly broken and not yet worth fixing. I know Joerg has a testing scheme in place, but I think it is not what you are talking about. See: http://xml.apache.org/fop/dev/testing.html WRT API dependencies, we need to either document them or delegate the management of them to someone who knows them. Please let me know if I need to fix something here. I seem to be hopelessly lost WRT where we are going with API issues, but as long as they don't prevent us from cleaning up FOP's underlying design, I'll be glad to help any way I can. Victor Mote
DO NOT REPLY [Bug 24658] New: - fo:external-graphic does not support SVG when src is an url
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=24658.
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=24658
fo:external-graphic does not support SVG when src is an url
Summary: fo:external-graphic does not support SVG when src is an
url
Product: Fop
Version: 0.20.5
Platform: All
OS/Version: Other
Status: NEW
Severity: Critical
Priority: Other
Component: svg
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi!
I found a problems when using urls instead of files for fo:external-graphic's
src paramater.
xsl:param name=imagebasehttp://localhost:8080/img/xsl:param
...
fo:external-graphic height=15pt width=180pt
xsl:attribute name=srcurl('xsl:value-of
select=$imagebase//SomePics.svg')/xsl:attribute
/fo:external-graphic
OR
fo:external-graphic height=15pt width=180pt
xsl:attribute name=srcxsl:value-of
select=$imagebase//SomePics.svg/xsl:attribute
/fo:external-graphic
does not work for IIS at all.
It works in 95% of all cases with APACHE.
It worka in 100% of all cases with files.
I get no exception(s) and - no pictures.
Any ideas?
FOP is 0.20.5 distribution.
Regards,
Joachim
RE: CVS (src bin) zip'd up for nightlies?
-Original Message- From: Clay Leeds [mailto:[EMAIL PROTECTED] Is it possible we could implement a system to get the CVS nightlies (src /or bin) for fop-1.0Dev zipped and/or tar'd for simple downloading and available from the Dev tab? Having to log in with CVS access is kind of a pain, and I don't know of another way to download the stuff. Maestro, Aren't these (sources) already at your disposal as the snapshots on http://cvs.apache.org/snapshots/xml-fop/ ? Just a guess... :) It might also be nice to have at least a most current (assuming there've been bugfixes ;-p) for the 0.20.5 version as well. These are not available, might come in handy, but would it still be worth the effort? I guess, to the extent possible, the actual link to the 0.20.5 distro should just point to a package for the latest update... Greetz, Andreas
DO NOT REPLY [Bug 24663] New: - fo:block space-after property needs fixing
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=24663. 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=24663 fo:block space-after property needs fixing Summary: fo:block space-after property needs fixing Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] As described in the below emails, some layout bugs are still present with the space-after property of fo:block: http://marc.theaimsgroup.com/?l=fop-devm=106858060129674w=2 http://marc.theaimsgroup.com/?l=fop-cvsm=106855860132454w=2
Re: CVS (src bin) zip'd up for nightlies?
On Wednesday, November 12, 2003, at 12:51 PM, Andreas L. Delmelle wrote: -Original Message- From: Clay Leeds [mailto:[EMAIL PROTECTED] Is it possible we could implement a system to get the CVS nightlies (src /or bin) for fop-1.0Dev zipped and/or tar'd for simple downloading and available from the Dev tab? Having to log in with CVS access is kind of a pain, and I don't know of another way to download the stuff. Maestro, Aren't these (sources) already at your disposal as the snapshots on http://cvs.apache.org/snapshots/xml-fop/ ? Just a guess... :) hehehe.. That's what I was looking for (I _thought_ there was a link like that!). Only problem is, I scoured the FOP Home and Development tabs and couldn't find it. If I couldn't find it after searching ( searching searching...), how's the average shmoe supposed to... wait a minute. I found the link. It's on the main FOP download page (not visible from the Dev tab). In addition, it doesn't indicate that it is fop-1.0DR1. I'd like to highlight the SNAPSHOT better to, among other things, properly identify the snapshots as being fop-1_0DR1 (or HEAD, or currently active FOP development branch or whatever the darn thing is called). For example, CURRENT: * Download a CVS snapshot from the cvs files here. These snapshots are built approximately every six hours, and have the GMT of their creation time embedded in their names. Please note that CVS snapshots are made only for the redesign branch. MODIFIED: * [b]FOP 1.0DR1 Snapshot[/b] - Download a CVS snapshot of FOP-1_0DR1 from the cvs files [a href=..]here[/a]. These snapshots are built approximately every six hours, and have the GMT of their creation time embedded in their names. Please note that CVS snapshots are made only for the redesign branch. BTW, IIRC it's been discussed on the list (ad nauseam) that the official tag name is HEAD, but frankly, I don't remember why so many terms appear to be synonymous. Unless I'm mistaken, the site refers to HEAD using the following other terms: Redesign (FOP=Download), FOP 1.0DR1 (FOP=Status), FOP-1.0Dev (don't recall where this was). Does it make sense to standardize on this and re-tag it in CVS? Should we also eradicate all other terms for it so visitors will know what to refer to? Obviously in the above modified paragraph redesign should be changed to whatever is decided. I'm not trying to be nit-picky here. I just don't want others to get confused as they try to figure this stuff out. It might also be nice to have at least a most current (assuming there've been bugfixes ;-p) for the 0.20.5 version as well. These are not available, might come in handy, but would it still be worth the effort? I guess, to the extent possible, the actual link to the 0.20.5 distro should just point to a package for the latest update... Greetz, Andreas I guess that's not really worth it, although to be honest I don't know if there've been any updates to the fop-0_20_2-maintain branch (i.e., 0.20.5). Have there been (the Release Notes don't indicate any changes)? If so, it might be good to identify what they are somewhere. If there are not, then never mind.
RT: line breaking
Victor Mote wrote: I know of at least two line-breaking strategies that we probably want to have in our stock strategies: 1) the line-by-line method used right now, and 2) a Tex-like paragraph-oriented strategy, which AFAIK doesn't exist yet. Ahem, that's not what I meant, or the scope of UTR14. UTR14 provides for line break opportunities, for example you can break foo-bar after the hyphen but not 789-123. Which opportunities are used is another matter. FOP's current algorithm for determining line break opportunities is utterly simplistic, basically possibly break before any breaking space, or after a hyphen or slash, the latter is done if hyphenation is enabled. I omitted the forced line break issue, which is also in the UTR14 scope, and hyphenation, which may lead to additional line break opportunities but is outside of the UTR14 scope. In your URL example, couldn't FOP see the x-url language automatically add or assume the glue characters for the user? That would perhaps make it less obtrusive (I assume that you meant for the user). Well, yes. I don't see it there yet, but I am a little confused. It seems to me that line-breaking consists of at least these components: 1) character-based line-breaking opportunities (which UTR14 addresses), 2) word-based line-breaking opportunities (which hyphenation dictionaries and patterns address), and 3) some strategy for using these to find acceptable/optimal line breaks. It sounds like you have addressed at least 1 and 3 in your implementation. Paragraph filling (your point 3) is not addressed. Be careful with the various TRs: UTR14 does not deal with character (rather: grapheme) or word boundaries, that's UTX-29. Actually, we don't use the latter. Our line breaking should probably be done the following way (this implements the naive paragraph filling strategy) loop calculate line width if next character is added check for a line breaking opportunity before the next character if there is an opportunity if the line is not full discard the last saved opportunity and save this else try hyphenation on the string accumulated since the last break opportunity (if enabled), save returned opportunity if any return saved line breaking opportunity end if end if end loop hyphenation of a string: loop skip non-word characters (for this hyphenator) word = continuous run of word characters (for this hyphenator) if the end of the word is past the end of the line try hyphenating the word, generate new break opportunities return best fitting line break opportunity or null end if end loop There is the degenerate case if the line overflows and no line break opportunity is discovered at all. The TeX paragraph filling strategy has to detect line break opportunities the same way but selects the opportunities turning into actual line breaks in a more clever way. We could do that too. This seems at least remotely related to fo.FOText.isWordChar(), which attempts to find breaks between words. Actually, we don't need breaks between words. We need identifying line breaking opportunities, words for the purpose of hyphenation, and resizable spaces for justification. That's why WordArea was such a bad name. J.Pietschmann
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TextLayoutManager.java
Glen Mazza wrote: Make sure you're separating the issues here... Uh, sorry the issue hasn't really much to do with your patch except that it is in roughly the same region of code... I should have started a new thread. Probably more than just Western, here's a Japanese description: http://java.sun.com/j2se/1.3/ja/docs/ja/api/java/text/BreakIterator.html Yeah, UTR-14 can handle japanese. However, it states explicitely it needs context in order to determine whether certain characters are handled as alphabetic (no breaks in between) or ideographic (break opportunity in between). I can't see how BreakIterator gets this. Yes. See http://java.sun.com/j2se/1.3/docs/api/index.html Darn! Didn't thought of the online docs! Again, I don't know the code, but it may be a good idea. Well, the problem is: BreakIterator returns on break opportunities. How would this fit into the LM framework? Anything that is based on Sun Java code (and an official standard like UTR14) probably makes our life much easier--anyone has a complaint about the hyphenation decisions can go complain to Sun about them! They don't deal with hyphenation, unfortunately. J.Pietschmann
Re: CVS (src bin) zip'd up for nightlies?
Clay Leeds wrote: BTW, IIRC it's been discussed on the list (ad nauseam) that the official tag name is HEAD, but frankly, I don't remember why so many terms appear to be synonymous. Yes, standardizing language in the docs makes sense. However re-tag it in CVS? I don't think this is appropriate or even necessary. I guess that's not really worth it, although to be honest I don't know if there've been any updates to the fop-0_20_2-maintain branch (i.e., 0.20.5). I've comitted the patch for early releasing areas generated by table FOs after the 0.20.5 final release, which is essential for rendering large tables without running out of memory. However, the AWT renderer gets NPEs occasionally, although I don't know whether this caused by my patch or something else. J.Pietschmann
DO NOT REPLY [Bug 24666] New: - fo:instream-foreign-object: SVG w/6-digit translates not rendering well
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=24666.
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=24666
fo:instream-foreign-object: SVG w/6-digit translates not rendering well
Summary: fo:instream-foreign-object: SVG w/6-digit translates not
rendering well
Product: Fop
Version: 1.0dev
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: svg
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Tom Vijlbrief has found errors with SVG containing 6-digit translates embedded
within FOP 0.20.5 (fo:instream-foreign-object) (Problem is also relevant for
1.0). The SVG renders fine with Batik's squiggle application (shows a
neighboorhood map.)
1st attachment -- SVG file (view via Squiggle).
2nd attachment -- FO file (which has above, plus one red one blue rectangle
for testing.)
3rd attachment -- (bad) PDF result
For 0.20.5, he has proposed this change to the PDFNumber.java class, which he
believes will accomodate PDFNumber receiving doubles in scientific notation
(e.g., 1E-04). (unsure of the validity of this.)
public class PDFNumber {
static java.text.DecimalFormat myFormatter = new java.text.DecimalFormat
(#.);
public static String doubleOut(Double doubleDown) {
return doubleOut(doubleDown.doubleValue());
}
public static String doubleOut(double doubleDown) {
return myFormatter.format(doubleDown);
}
public static String doubleOut(double doubleDown, int dec) {
return doubleOut(doubleDown);
}
... other methods in 1.0...
}
The new class appears to fix the problem when applied to 0.20.5, however will
*not* work with nightly build of maintenance (has a different Batik library).
Nor will it work with 1.0, because of the (even newer) Batik library in HEAD
(as well as perhaps other reasons, 1.0 being incomplete).
Another possible problem with the above patch is that it neutralizes the third
method in the class (just calls the second method, # decimal points desired is
ignored). I'm unsure how important the third method is to FOP.
4th attachment -- PDF result from 0.20.5 modified with PDFNumber as above.
Renders well
Thomas DeWeese (Batik) commented on this problem earlier, prior to Tom
Vijlbrief's patch:
see http://marc.theaimsgroup.com/?l=fop-devm=106709286423914w=2.
Will keep this bug open for 1.0 to ensure that these types of SVG's can be
generated in the new 1.0 version of FOP. Also, the rendering is usually worse
in Acrobat Reader 5.0 vs. AR 6.0, so recommended to make sure changes render
correctly at least in AR 6.0.
DO NOT REPLY [Bug 24666] - fo:instream-foreign-object: SVG w/6-digit translates not rendering well
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=24666. 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=24666 fo:instream-foreign-object: SVG w/6-digit translates not rendering well --- Additional Comments From [EMAIL PROTECTED] 2003-11-12 23:20 --- Created an attachment (id=9080) SVG file that renders correctly w/Squiggle application.
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-11-12 23:40 --- Tom, Your patch fixed things quite well in 0.20.5--I tested it--*but* the nightly maintenance version of 0.20.5 has a different Batik library (a version of a couple of months ago, that we had to update because of an API change) that your patch would *not* fix. We're going to pass on making the change in 0.20.5 (maintenance is mostly frozen anyway). Your patch has the same problems with 1.0, which has an even newer Batik library, however, there may be also other issues in 1.0 causing the problem there.) There may be other issues as well with the patch you supplied, namely the loss of the third method which allows one to choose the number of desired decimal points--I'm unsure how needed it is right now. (Also, I'm unclear how exponential notation is an issue with the double data type--that should be understood inherently with that datatype, correct? Nonetheless, your patch *did* fix the problem.) Some of our more experienced SVG developers may be able to comment on this later for 1.0. The bug below has gotten too huge for anyone to look at, so I just took the relevant points and redid the bug in #24666. Clearly, this is something that needs fixing but we'll concentrate on making sure it will be OK in 1.0 instead. Thanks, Glen *** This bug has been marked as a duplicate of 24666 ***
DO NOT REPLY [Bug 24666] - fo:instream-foreign-object: SVG w/6-digit translates not rendering well
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=24666. 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=24666 fo:instream-foreign-object: SVG w/6-digit translates not rendering well [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-11-12 23:40 --- *** Bug 23883 has been marked as a duplicate of this bug. ***
Re: RT: line breaking
J.Pietschmann wrote: Be careful with the various TRs: UTR14 does not deal with character (rather: grapheme) or word boundaries, that's UTX-29. Actually, we don't use the latter. Our line breaking should probably be done the following way (this implements the naive paragraph filling strategy) loop calculate line width if next character is added check for a line breaking opportunity before the next character if there is an opportunity if the line is not full discard the last saved opportunity and save this else try hyphenation on the string accumulated since the last break opportunity (if enabled), save returned opportunity if any return saved line breaking opportunity end if end if end loop hyphenation of a string: loop skip non-word characters (for this hyphenator) word = continuous run of word characters (for this hyphenator) if the end of the word is past the end of the line try hyphenating the word, generate new break opportunities return best fitting line break opportunity or null end if end loop There is the degenerate case if the line overflows and no line break opportunity is discovered at all. The TeX paragraph filling strategy has to detect line break opportunities the same way but selects the opportunities turning into actual line breaks in a more clever way. We could do that too. In my own thinking about the process of line-breaking, I have always assumed that a (possibly recursive) block of text is a fixed resource; a superset of the fixed resource that is a single glyph/grapheme with given font attributes. As such, it should be processed by a separate co-routine (to use the language of the Rec). All of the information about the hierarchy of potential break positions is determined by the text itself. As a first cut, I would I would determine all potential breaks, along with information relevant to later line-height calculations, at the time a block is first prepared for layout. The co-routine (thread, whatever) that is grooming the text would then respond to enquiries about line-area possibilities, and eventually return contents for line-areas of particular dimensions. All of this is tentative, and all of the calculated information about the block would have to be held until the layout of the block is finalised. What finalised means depends on the complexity of the layout strategies employed, but at a minimum, it must be maintained until the last page containing text from the block, and the subsequent page (if any) have been laid out, to allow for backtracking during last-page processing. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
