[GUMP@brutus]: Project cocoon-block-fop (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - cocoon-block-fop : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop-block.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: xml-fop-maintenance unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/rss.xml - Atom: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2425112004, brutus:brutus-public:2425112004 Gump E-mail Identifier (unique within run) #32. -- Apache Gump http://gump.apache.org/ [Instance: brutus]
Re: Unnecessary zipping and backups?
The Web Maestro wrote:
[..]
On a similar note, I am 'contemplating' committing the xml-fop/build/
folder ('built' by apache-forrest-0.6). My reasoning for this is
two-fold: 1. it contains the FOP web site (which I've spent a
significant amount of time to re-create).
The generated website should actually be commited to the xml-site
repository (targets/fop) and the live site updated from there.
Sorry, no more time right now (hopefully I'll get some this evening)
Christian
DO NOT REPLY [Bug 32391] New: - Wrong font selection with awt (print)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32391. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32391 Summary: Wrong font selection with awt (print) Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: awt renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I use a user defined font e.g Arial, that have more than one TTF file (arial.ttf, arialbd.ttf, ...), the font selection is wrong when I switch back from bold to normal. The first way (normal to bold) works fine, but the way back use the bold font file for the normal font. I located the problem in AWTFontMetrics.java::setFont(). The Buffered font. f1 in the source doesn't switch back to normal. The font family is equal, but the style is different, so that the line: f1 = f1.deriveFont(style, (float)s); select the wrong font (style bold, metrics normal (looks ugly) ). My local workaround was: disable caching, always create a new font. Thomas -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Unnecessary zipping and backups?
On Nov 24, 2004, at 5:19 PM, Peter B. West wrote: Clay, Let me say, Clay, thank you *very*, *very* much for taking care of the alt-design tab. Have I drawn your attention to the fact that I am *very happy* that you have taken care of this? (I have thanked Clay personally out-of-band for his work on this.) Peter You are welcome, Peter. Thank you for your kind words! I am just glad to finally be done with that process. FWIW fop-dev, I created a mini-site of alt.design and put it on my home page: http://homepage.mac.com/webmaestro/defoe/ (the only change, is that I skinned it, and created the few Forrest-specific files: forrest.properties, skinconf.xml, site.xml tabs.xml). I also zipped it up: http://homepage.mac.com/webmaestro/defoe.zip Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
For our American readers...
Happy Thanksgiving! (--that is the 25th, right? :-P) Greetz, Andreas
Re: For our American readers...
Thanks (but to Him, not to me!), Glen http://holydays.tripod.com/linc.htm --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Happy Thanksgiving! (--that is the 25th, right? :-P) Greetz, Andreas
Re: Do we need an inherit enumeration constant?
[Finn] It [an INHERIT constant] isn't needed as an enum value because the 'inherit' keyword takes precedence over the other enumeration values. See 5.9.11: The Keyword values take precedence over EnumerationToken. where Keyword is 'inherit'. The code to handle 'inherit' is at line 397 http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/properties/Proper tyMaker.java?annotate=1.11 [Glen] Finn, I've read what you've written above, as well as what the spec is saying -- but I am confused here. Why does there need to be a precedence-determining rule in the spec that says The Keyword values take precedence over EnumerationToken.? Does anyone know? My first thought is that we're only going to have one attribute value between the quotes (i.e., inherit, left, right, justify, etc.) so I don't see the need for order-of-evaluation rules or declarations of precedence. But are there actually cases where you would have more than one enumeration constant (e.g., left | justify?) I must be missing something here. Thanks, Glen
Re: Do we need an inherit enumeration constant?
[Finn] It [an INHERIT constant] isn't needed as an enum value because the 'inherit' keyword takes precedence over the other enumeration values. See 5.9.11: The Keyword values take precedence over EnumerationToken. where Keyword is 'inherit'. The code to handle 'inherit' is at line 397 http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/properties/Proper tyMaker.java?annotate=1.11 [Glen] Finn, I've read what you've written above, as well as what the spec is saying -- but I am confused here. Why does there need to be a precedence-determining rule in the spec that says The Keyword values take precedence over EnumerationToken.? Does anyone know? Perhaps because 'Keyword' and 'EnumerationToken' is produces with the same lexical rule. http://www.w3.org/TR/REC-xml-names/#NT-NCName My first thought is that we're only going to have one attribute value between the quotes (i.e., inherit, left, right, justify, etc.) so I don't see the need for order-of-evaluation rules or declarations of precedence. But are there actually cases where you would have more than one enumeration constant (e.g., left | justify?) I must be missing something here. 'azimuth' and 'text-decoration' can have multiple enum values (eg. overline line-through). But no property can have inherit as well as some other value. regards, finn
Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java
[EMAIL PROTECTED] wrote: gmazza 2004/11/24 13:07:31 2.) Appended EN_ to enumeration constants to make them better SR'able throughout app. Yuk. Having a large number of identifiers in the same scope with an identical prefix isn't very good for autocompletion both in Emacs and Eclipse. I also don't quite get the point about the better SR'ability. J.Pietschmann
Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java
--- J.Pietschmann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: gmazza 2004/11/24 13:07:31 2.) Appended EN_ to enumeration constants to make them better SR'able throughout app. Yuk. Having a large number of identifiers in the same scope with an identical prefix isn't very good for autocompletion both in Emacs and Eclipse. We've been doing the same with PR_ (properties) and FO_ (FO's) for quite some time. After hitting the EN_, you're at the same place you would be without the prefix. Furthermore, you can now hunt away for your enumeration constants without them being intermixed with the PR_'s and FO_'s. It was also a commenting issue: TRUE and FALSE, for example, without a prefix, just weren't self documenting enough to emphasize that we're working with enumeration constants here. (Remember, we removed the old interfaces--per your desire as well as mine--such as WritingMode.LR_TB or whatever that previously provided that emphasis.) I also don't quite get the point about the better SR'ability. Because it gives us a very convenient handle (EN_) to identify all the places where enumeration constants are currently being used. So if we wanted to switch from EN_, to ENUM_, it would just be a quick SR. Sans handle, that would be a very cumbersome file-by-file manual process--which I just did yesterday, in order to get the EN_'s in place to begin with. Glen
Re: For our American readers...
On Nov 25, 2004, at 9:09 AM, Andreas L. Delmelle wrote: Happy Thanksgiving! (--that is the 25th, right? :-P) Greetz, Andreas I would consider it not just for Americans, but I also give thanks for the entire FOP community which gives so much, and takes so little! Cheers! Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
