DO NOT REPLY [Bug 15992] New: - Single graphic in column followed by span-all block 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=15992. 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=15992 Single graphic in column followed by span-all block causes infinite loop Summary: Single graphic in column followed by span-all block causes infinite loop Product: Fop Version: 0.20.4 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following conditions cause what appears to be an infinite loop in the fop processor: - fo:flow defined with multiple columns - fo:block #1 contains just one single external graphic - fo:block #2 (follows fo:block #1) has attribute span=all I will include the .fo file. I am running JDK1.3.0_02. The command used: fop columnbug.fo columnbug.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Encryption
Jeremias, Ok... it now works with bouncycastle's implementation. I need to add a couple more days, we are moving our offices. It was majorly bungled and it is eating up a lot of time. Pat -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 2:07 AM To: [EMAIL PROTECTED] Subject: Re: Encryption Hi Patrick That's great news! I'll be glad to help testing and integrating. But one question: Why would you want to implement RC4 yourself? Wouldn't it be better if we used (for example) bouncycastle.org's implementation for that? They have an MIT licence which is compatible with the APL AFAIK. You wouldn't have to do any debugging and testing on the cryptography stuff that way. On 10.01.2003 00:25:16 Patrick C. Lankswert wrote: Thanks for the reply. Outside of clean up, I have working code. It is limited since only PDF 1.3 is supported by FOP and I am currently using a non-commercial RC4 implementation. If I get the time, I could have it cleaned up in a week and a half. It might be a little longer if I go ahead and implement RC4 myself. I might need some help testing, but I already have it generating encrypted PDFs with and without passwords, permissions etc. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
Hi Jeff I've applied your patches locally. Thanks. Everything's ok with the first one, but with the second one I'm having problems (not your fault!): - I had to add adjust the inline DTD of skinconf.xml to include the role attribute: !ELEMENT credit (name, url, image, width?, height?) !ATTLIST credit role CDATA #IMPLIED - The credit element produces a rather ugly FOP logo. But that's probably more a FOP-internal thing. We probably need a customized little image for this. It should probably be something like: PDFs generated with logo F O P Questions: - Does anyone have the original logo (AI, CorelDraw, SVG etc.)??? I haven't found it anywhere. - Do we like our current logo? :-) I've commented out Jeff's credit element for the moment and will commit the changes in a minute. On 10.01.2003 15:45:11 Jeff Turner wrote: Running 'forrest validate' on CVS head, I get: validate-xdocs: /home/jeff/apache/xml/xml-fop/src/documentation/content/xdocs/design/alt.design/properties/enumerated-values.xml:211:63: Element type code. must be declared. /home/jeff/apache/xml/xml-fop/src/documentation/content/xdocs/design/alt.design/properties/enumerated-values.xml:212:44: The element type code. must be terminated by the matching end-tag /code.. Attached patch fixes this, and cleans up enumerated-values.xml a bit. Also, I've just modified Forrest so that the xml-fop/src/documentation/forrest.diff patch is no longer necessary. To achieve the same effect, the second attached patch adds this to src/documentation/skinconf.xml: +credit role=pdf + nameCreated by: FOP 1.0dev/name + urlhttp://xml.apache.org/fop/dev/url + imageimages/logo.jpg/image + width138/width + height31/height +/credit The image, width and height fields are unused, but I put them there so users with pre-patched Forrests (which don't know about @role) don't get a broken link on the HTML front-page. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/design/alt.design/properties enumerated-values.xml
jeremias2003/01/11 08:49:26 Modified:src/documentation skinconf.xml src/documentation/content/xdocs/design/alt.design/properties enumerated-values.xml Removed: src/documentation forrest.diff Log: Fixed validation errors forrest.diff no longer necessary due to changes in Forrest Little FOP logo in credits line (commented out, discussion pending) Submitted by: Jeff Turner [EMAIL PROTECTED] Updated skinconf.xml's DTD Updated year Revision ChangesPath 1.4 +9 -1 xml-fop/src/documentation/skinconf.xml Index: skinconf.xml === RCS file: /home/cvs/xml-fop/src/documentation/skinconf.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- skinconf.xml 2 Jan 2003 13:01:12 - 1.3 +++ skinconf.xml 11 Jan 2003 16:49:26 - 1.4 @@ -14,6 +14,7 @@ !ELEMENT skinconfig (disable-search?, searchsite-domain?, searchsite-name?, project-name, project-url, project-logo, group-name?, group-url?, group-logo?, host-logo?, year?, vendor?, trail?, credits?)* !ELEMENT credits (credit*) !ELEMENT credit (name, url, image, width?, height?) + !ATTLIST credit role CDATA #IMPLIED !ELEMENT disable-search (#PCDATA) !ELEMENT searchsite-domain (#PCDATA) !ELEMENT searchsite-name (#PCDATA) @@ -60,7 +61,7 @@ host-logo/host-logo !-- The following used to construct a copyright statement -- - year1999-2002/year + year1999-2003/year vendorThe Apache Software Foundation./vendor !-- Some skins use this to form a 'breadcrumb trail' of links. If you don't @@ -89,5 +90,12 @@ width138/width height31/height /credit-- +!--credit role=pdf + nameCreated by: FOP 1.0dev/name + urlhttp://xml.apache.org/fop/dev/url + imageimages/logo.jpg/image + width138/width + height31/height +/credit-- /credits /skinconfig 1.2 +73 -73 xml-fop/src/documentation/content/xdocs/design/alt.design/properties/enumerated-values.xml Index: enumerated-values.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/design/alt.design/properties/enumerated-values.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- enumerated-values.xml 27 Dec 2002 07:50:16 - 1.1 +++ enumerated-values.xml 11 Jan 2003 16:49:26 - 1.2 @@ -15,8 +15,8 @@ must provide a way of translating between the tokens and the integers, and emvice versa/em. Depending on the number of tokens in an enumeration set, the mapping from token to -integer is maintained in an array or a code HashMap/code . -The switch-over point from array to code HashMap/code was +integer is maintained in an array or a codeHashMap/code. +The switch-over point from array to codeHashMap/code was determined by some highly implementation-dependent testing to be in the region of four to five elements. /p @@ -33,34 +33,34 @@ p fork href= Direction.html code - org.apache.fop.fo.properties.Direction/code /fork is an + org.apache.fop.fo.properties.Direction/code/fork is an example of a class which supports an enumerated value with a small set of tokens. The fork href= - Direction.html#dataTypes code dataTypes/code /fork + Direction.html#dataTypes codedataTypes/code/fork field contains the fork href= Property.html#NOTYPE code - ENUM/code data type constant, defined in code - Property/code /fork . The enumeration integer constants - are defined as code public static final int/code - values, fork href= Direction.html#LTR code LTR/code - and code RTL/code /fork . Associating enumeration + ENUM/code data type constant, defined in code + Property/code/fork . The enumeration integer constants + are defined as codepublic static final int/code + values, fork href= Direction.html#LTR codeLTR/code + and codeRTL/code/fork . Associating enumeration tokens with these integer constants occurs in the array - fork href= Direction.html#rwEnums code String[] - rwEnums/code /fork , which is initialized with the token + fork href= Direction.html#rwEnums codeString[] + rwEnums/code/fork , which is initialized with the token strings. By convention, zero is never used to represent a valid enumeration constant, anywhere in this code. It is, of course, critical that synchronization between code -
RE: thoughts on fonts (was: text-decoration)
Keiron Liddle wrote:
If I understand it correctly we could have:
- multiple output targets for one rendering run
- targets with the same font metrics can layout to a common area tree
- targets with similar or substitute metrics could force layout
to one area tree
- other targets can have different area trees from the same fo tree
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
2. If we have a RenderingContext concept, doesn't that mean that we need to
know what that RenderingContext is for each output target before we start
processing? To do any good, we must sort like RenderingContexts process
them together. Since we don't complete parsing of the document until the
very end, it seems like we would have to parse the complete document before
knowing what the Context looks like.
3. If we were to switch to a model that completely parses the document at
the beginning (looking for RenderingContext differences), then we might want
to build the FO tree at the same time?
4. If we build the FO tree up front let it persist, then you can achieve
the same thing in series instead of in parallel. (All of this comes at the
price of greater memory consumption, or else caching). For example:
parse doc, build FO tree, build RenderingContexts
for each RenderingContext {
build an area tree
for each output medium in this RenderingContext {
render
}
delete area tree
}
Even in this serial design, you could multi-thread either or both of the two
loops.
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
Jeremias Maerki wrote: - Do we like our current logo? :-) That's a big question actually :) afair Keiron said the current logo should be at least brighten to fit forrest-ed site design better or suggested to make the logo contest. Should admit I spent a couple of hours trying to implement my ideas about the logo (leading motifs were medieval typographic dropcaps and a parrot as (imho) the most foppish animal) but I'm too bad artist and the results were too ugly :) My suggestion is to announce the new FOP logo contest in fop-user list or broader, like recent Amaya welcome page contest[1] (the winner gets bragging rights). Then we can vote among developers or users, how the idea? [1] http://www.w3.org/Amaya/contest.html -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDF Output consideration 1.3 vs. 1.4
Since you are currently discussing PDF 1.3 vs. 1.4 issues, there's one thing not all of you may be aware of: There's a relatively new standard called PDF/X-3. This is basically PDF 1.3 with a number of restrictions. Some can be handled by the user (all fonts must be embedded), some others must be adhered to by the PDF generator. The intention of PDF/X is to standardize on a PDF subset that can be handled without the usual problems in the prepress business (missing or mismatched fonts, color mismatches, trapping etc.). For more information see http://www.pdfx.info. There's also a freeware PDF/X preflight tool called PDF/X-3 Inspector (download URL: http://www.pdfx.info/download.html). The reason I'm mentioning this is that one of the restrictions of PDF/X-3 is that the PDF file may not be PDF 1.4 (I'm not sure if lower than 1.3 is ok). To pave the way for future PDF/X support, you may consider still supporting PDF 1.3 in the redesign code tree. At least perhaps make it configurable. Hope this information is useful. -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: coordinates
Keiron Liddle wrote:
That appears to be the old coordinate system which was tied to the pdf
coordinate system.
The new way is to have 0,0 at the top left.
It appears that some of the page master stuff hasn't been updated.
I fixed that a little bit, now regions are placed ok in lr-tb, rl-tb and
tb-rl modes, what else may still not be updated?
btw, how can I define *value* shortcut in properies file? I mean lr, rl
and tb writing modes (I know, shortcuts are not basic level but these
don't require any efforts to implement) - they are simply shortcuts for
lr-tb, rl-tb and tb-rl, so property maker should just have
if (value.equals(lr-tb)) { return s_propLR_TB; }
if (value.equals(lr)) { return s_propLR_TB; }
If it's not implemented I'm volunteering to do it.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: text-decoration
Keiron Liddle wrote: Have you managed to work out how the underline/overline should work, for example when there are embedded inline areas that contain a different font, colour or baseline. Well, not really. I just wanted to make something simple done :) afaiu different font/colour/etc embedded inlines will generate different Word with different traits, right? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop CHANGES
pietsch 2003/01/11 10:24:04 Modified:.Tag: fop-0_20_2-maintain CHANGES Log: Added changes for 0.20.5 Revision ChangesPath No revision No revision 1.10.2.39 +19 -0 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.38 retrieving revision 1.10.2.39 diff -u -r1.10.2.38 -r1.10.2.39 --- CHANGES 9 Jan 2003 13:47:25 - 1.10.2.38 +++ CHANGES 11 Jan 2003 18:24:04 - 1.10.2.39 @@ -52,6 +52,25 @@ Submitted by: Stephen Wolke [EMAIL PROTECTED] - Added a property on the PostScript renderer for switching between PostScript Level 2 and 3. Default is Level 3. (Jeremias Maerki) +- Improved standard conformance for forced page counts (J.Pietschmann) +- Better error reporting for common problems (invalid page master references, + missing table-body elements) (J.Pietschmann) +- Improved handling of text containing entity references. (J.Pietschmann) +- Made marker references work for markers not from the current page, + with some caveats (J.Pietschmann) +- Simplification of ASCII85 computation, work around for a JVM bug on Linux + (J.Pietschmann) +- Fixed width calculation for spaces (J.Pietschmann) +- Fixed problems with setting text decorations on fo:wrapper. (J.Pietschmann) +- Automatic compilation on Java1.4 (J.Pietschmann) +- More possiblities to pass data to FOP (J.Pietschmann) +- Fixed missing Ids for table rows (#12876) (J.Pietschmann) +- Page number citations are now correctly formatted (#13691) (J.Pietschmann) +- Text decoration and links now work with hyphenated words. (#4511) + (J.Pietschmann) +- Fixed problems with scrambled and lost related to hyphenation (#6042 + and a few others). (J.Pietschmann) +- Fixed wrong space generation related to hyphenation. (J.Pietschmann) == Done since 0.20.3 release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
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=15985. 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=15985 Hyphenation pattern files appear to be invalid --- Additional Comments From [EMAIL PROTECTED] 2003-01-11 18:36 --- Yes, that looks like extremely quirky environment problem. *.hyp files are serialized HyphenationTree objects, which are serialized during build process. afaiu the exception means hyp file cannot be deserialized into HyphenationTree object due to version inconsistency. Make sure you don't have another fop.jar or fop classes or hyp files somewhere in the classpath. Try to rebuild fop after all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
Oleg Tkachenko wrote: Jeremias Maerki wrote: - Do we like our current logo? :-) Uh! Should admit I spent a couple of hours trying to implement my ideas about the logo (leading motifs were medieval typographic dropcaps and a parrot as (imho) the most foppish animal) but I'm too bad artist and the results were too ugly :) What about a TeX-parody? +--- +--\ | | | +-- /--\ +--/ | || | | || | || \--/ Colored as the current logo, or more in shades like the Apache feather? (feather - part of a parrot - hmm) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render AbstractRenderer.java
pietsch 2003/01/11 10:43:04
Modified:src/org/apache/fop/layout Tag: fop-0_20_2-maintain
LineArea.java
src/org/apache/fop/render Tag: fop-0_20_2-maintain
AbstractRenderer.java
Log:
Added diagnostic for probably dropped text due to unhandled pending inline areas.
Revision ChangesPath
No revision
No revision
1.53.2.12 +3 -2 xml-fop/src/org/apache/fop/layout/Attic/LineArea.java
Index: LineArea.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layout/Attic/LineArea.java,v
retrieving revision 1.53.2.11
retrieving revision 1.53.2.12
diff -u -r1.53.2.11 -r1.53.2.12
--- LineArea.java 19 Nov 2002 01:04:08 - 1.53.2.11
+++ LineArea.java 11 Jan 2003 18:43:04 - 1.53.2.12
@@ -92,7 +92,8 @@
protected ArrayList pendingAreas = new ArrayList();
/* the width of the pendingAreas */
-protected int pendingWidth = 0;
+/* public for problem check in AbstractRenderer */
+public int pendingWidth = 0;
/* text-decoration of the previous text */
protected boolean prevUlState = false;
No revision
No revision
1.4.2.7 +6 -1 xml-fop/src/org/apache/fop/render/AbstractRenderer.java
Index: AbstractRenderer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/AbstractRenderer.java,v
retrieving revision 1.4.2.6
retrieving revision 1.4.2.7
diff -u -r1.4.2.6 -r1.4.2.7
--- AbstractRenderer.java 8 Nov 2002 10:25:27 - 1.4.2.6
+++ AbstractRenderer.java 11 Jan 2003 18:43:04 - 1.4.2.7
@@ -451,6 +451,11 @@
* @param area area to render
*/
public void renderLineArea(LineArea area) {
+if (area.pendingWidth0) {
+log.error(Areas pending, text probably lost. Check Page +
+ area.getPage().getFormattedNumber() +
+ and following page.);
+}
int rx = this.currentAreaContainerXPosition + area.getStartIndent();
int ry = this.currentYPosition;
int w = area.getContentWidth();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
the logo (Re: [PATCH] doc validation fix)
J.Pietschmann wrote: What about a TeX-parody? +--- +--\ | | | +-- /--\ +--/ | || | | || | || \--/ Not bad, but what does it mean? (And does logo should mean anything?) :) Colored as the current logo, or more in shades like the Apache feather? (feather - part of a parrot - hmm) I've been imagining F and P as fancy dropcaps and/or a little o with a parrot sitting on it, colored or just outlined (something like this one [1]). Anyway each of us has a great imagination, but we need real logos to choose and why not to make a contest? It's kind of PR after all. [1] http://www.nyc-poly.org/Poly%20parrot.gif -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/examples - New directory
jeremias2003/01/11 12:49:23 xml-fop/examples - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding - New directory
jeremias2003/01/11 12:50:07 xml-fop/examples/embedding - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding/java - New directory
jeremias2003/01/11 12:50:31 xml-fop/examples/embedding/java - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding/xml - New directory
jeremias2003/01/11 12:50:35 xml-fop/examples/embedding/xml - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding/java/embedding - New directory
jeremias2003/01/11 12:50:51 xml-fop/examples/embedding/java/embedding - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding/java/embedding/model - New directory
jeremias2003/01/11 12:51:03 xml-fop/examples/embedding/java/embedding/model - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding/java/embedding/tools - New directory
jeremias2003/01/11 12:51:07 xml-fop/examples/embedding/java/embedding/tools - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding/xml/xslt - New directory
jeremias2003/01/11 12:52:10 xml-fop/examples/embedding/xml/xslt - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/examples/embedding/xml/xslt projectteam2fo.xsl
jeremias2003/01/11 12:54:02 Added: examples/embedding Tag: fop-0_20_2-maintain .cvsignore README build.bat build.sh build.xml examples/embedding/java/embedding Tag: fop-0_20_2-maintain ExampleFO2PDF.java ExampleObj2PDF.java ExampleObj2XML.java ExampleXML2FO.java ExampleXML2PDF.java examples/embedding/java/embedding/model Tag: fop-0_20_2-maintain ProjectMember.java ProjectTeam.java ProjectTeamInputSource.java ProjectTeamXMLReader.java examples/embedding/java/embedding/tools Tag: fop-0_20_2-maintain AbstractObjectReader.java EasyGenerationContentHandlerProxy.java examples/embedding/xml/fo Tag: fop-0_20_2-maintain helloworld.fo examples/embedding/xml/xml Tag: fop-0_20_2-maintain projectteam.xml examples/embedding/xml/xslt Tag: fop-0_20_2-maintain projectteam2fo.xsl Log: Added first set of embedding examples (formerly known as tutorial). Documentation will be added in the next couple of days. Revision ChangesPath No revision No revision 1.1.2.1 +2 -0 xml-fop/examples/embedding/Attic/.cvsignore 1.1.2.1 +17 -0 xml-fop/examples/embedding/Attic/README 1.1.2.1 +34 -0 xml-fop/examples/embedding/Attic/build.bat 1.1.2.1 +29 -0 xml-fop/examples/embedding/Attic/build.sh 1.1.2.1 +111 -0xml-fop/examples/embedding/Attic/build.xml No revision No revision 1.1.2.1 +95 -0 xml-fop/examples/embedding/java/embedding/Attic/ExampleFO2PDF.java 1.1.2.1 +107 -0 xml-fop/examples/embedding/java/embedding/Attic/ExampleObj2PDF.java 1.1.2.1 +93 -0 xml-fop/examples/embedding/java/embedding/Attic/ExampleObj2XML.java 1.1.2.1 +86 -0 xml-fop/examples/embedding/java/embedding/Attic/ExampleXML2FO.java 1.1.2.1 +105 -0 xml-fop/examples/embedding/java/embedding/Attic/ExampleXML2PDF.java No revision No revision 1.1.2.1 +91 -0 xml-fop/examples/embedding/java/embedding/model/Attic/ProjectMember.java 1.1.2.1 +70 -0 xml-fop/examples/embedding/java/embedding/model/Attic/ProjectTeam.java 1.1.2.1 +39 -0 xml-fop/examples/embedding/java/embedding/model/Attic/ProjectTeamInputSource.java 1.1.2.1 +104 -0 xml-fop/examples/embedding/java/embedding/model/Attic/ProjectTeamXMLReader.java No revision No revision 1.1.2.1 +166 -0 xml-fop/examples/embedding/java/embedding/tools/Attic/AbstractObjectReader.java 1.1.2.1 +199 -0 xml-fop/examples/embedding/java/embedding/tools/Attic/EasyGenerationContentHandlerProxy.java No revision No revision 1.1.2.1 +13 -0 xml-fop/examples/embedding/xml/fo/Attic/helloworld.fo No revision No revision 1.1.2.1 +29 -0 xml-fop/examples/embedding/xml/xml/Attic/projectteam.xml No revision No revision 1.1.2.1 +57 -0 xml-fop/examples/embedding/xml/xslt/Attic/projectteam2fo.xsl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding examples (or tutorial) and new directory structure
Jeremias Maerki wrote: I'd like to get rid of the docs directory in the end. I think there's still the -1 from Oleg concerning the src/foschema. How do we resolve that? We've got: 1. src/foschema (my proposal, +1 from Keiron and Jörg) 2. src/documentation/test/foschema (Oleg's preferred location. Did I get you right on this?) I don't remember actually, but considering src/java I'm ok with src/foschema. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Cleanups in enumerated-values.xml
The code. elements obviously had to be cleaned up, but I am little saddened that the code elements have been compressed. I have tended to use the spaces when I find myself with long sequences of characters which do not wrap easily. Judiciously applied spaces provide multiple wrap points for the folding algorithm. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Victor Mote wrote: There are some big picture things that we should probably address: 1. (Biggest of all) Do we have users that need to be able to do this? Are the performance gains that they might get worth the pain on our end? Apart from this is the fact that our processing model for any rendering is still very much in a state of flux. It may be less painful to retro-fit when we have a comprehensive working renderer, keeping this possibility in mind as we go. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP logo
J.Pietschmann wrote: Oleg Tkachenko wrote: Jeremias Maerki wrote: - Do we like our current logo? :-) Uh! Should admit I spent a couple of hours trying to implement my ideas about the logo (leading motifs were medieval typographic dropcaps and a parrot as (imho) the most foppish animal) but I'm too bad artist and the results were too ugly :) What about a TeX-parody? +--- +--\ | | | +-- /--\ +--/ | || | | || | || \--/ Colored as the current logo, or more in shades like the Apache feather? (feather - part of a parrot - hmm) Clare's designs (see previous post) were based on a quill inking in the P in a large FOP on a page which also contained Chancery-stle text in a smaller font. The quill was originally supposed to be a connection with the Apache feather, but apparently that particular feather didn't work, and the Apache colours were too garish. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
Victor Mote wrote: Jeremias Maerki wrote: - Do we like our current logo? :-) I hope I am not out of line to ask an even more fundamental question -- do we like our current name? I never have a problem writing it, but when speaking it, I cannot make my mouth say fop, but invariably say eff-oh-pee instead. Heresy! Victor, the stigma that once attached to consulting a speech therapist has almost vanished now. I'm sure something can be done, and our best wishes will go with you. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] doc validation fix
On Sat, Jan 11, 2003 at 05:43:37PM +0100, Jeremias Maerki wrote: Hi Jeff I've applied your patches locally. Thanks. Everything's ok with the first one, but with the second one I'm having problems (not your fault!): - I had to add adjust the inline DTD of skinconf.xml to include the role attribute: !ELEMENT credit (name, url, image, width?, height?) !ATTLIST credit role CDATA #IMPLIED Oops yes, sorry. Attached is a fix with DTD mods. - The credit element produces a rather ugly FOP logo. If you upgrade your Forrest, the logo won't appear[1]. The @role=pdf in skinconf.xml means the credit only applies to PDFs. Earlier versions of Forrest didn't know about this, so rather than display a broken image, I threw in the current FOP logo. --Jeff [1] See http://forrestbot.cocoondev.org/sites/xml-fop/ (after applying the patch) But that's probably more a FOP-internal thing. We probably need a customized little image for this. It should probably be something like: PDFs generated with logo F O P Questions: - Does anyone have the original logo (AI, CorelDraw, SVG etc.)??? I haven't found it anywhere. - Do we like our current logo? :-) I've commented out Jeff's credit element for the moment and will commit the changes in a minute. ... Index: src/documentation/skinconf.xml === RCS file: /home/cvspublic/xml-fop/src/documentation/skinconf.xml,v retrieving revision 1.4 diff -u -r1.4 skinconf.xml --- src/documentation/skinconf.xml 11 Jan 2003 16:49:26 - 1.4 +++ src/documentation/skinconf.xml 12 Jan 2003 03:47:16 - @@ -11,10 +11,14 @@ !ENTITY % links.att 'name CDATA #REQUIRED' !ENTITY % link.att 'name CDATA #REQUIRED href CDATA #REQUIRED' - !ELEMENT skinconfig (disable-search?, searchsite-domain?, searchsite-name?, project-name, project-url, project-logo, group-name?, group-url?, group-logo?, host-logo?, year?, vendor?, trail?, credits?)* + !ELEMENT skinconfig (disable-search?, searchsite-domain?, searchsite-name?, + project-name, project-url, project-logo, group-name?, group-url?, group-logo?, + host-url?, host-logo?, year?, vendor?, trail?, credits?)* !ELEMENT credits (credit*) - !ELEMENT credit (name, url, image, width?, height?) - !ATTLIST credit role CDATA #IMPLIED + !ELEMENT credit (name, url, image?, width?, height?) + !-- id uniquely identifies the tool, and role indicates its function -- + !ATTLIST credit id CDATA #IMPLIED + role CDATA #IMPLIED !ELEMENT disable-search (#PCDATA) !ELEMENT searchsite-domain (#PCDATA) !ELEMENT searchsite-name (#PCDATA) @@ -24,6 +28,7 @@ !ELEMENT group-name (#PCDATA) !ELEMENT group-url (#PCDATA) !ELEMENT group-logo (#PCDATA) + !ELEMENT host-url (#PCDATA) !ELEMENT host-logo (#PCDATA) !ELEMENT year (#PCDATA) !ELEMENT vendor (#PCDATA) @@ -90,12 +95,12 @@ width138/width height31/height /credit-- -!--credit role=pdf +credit role=pdf nameCreated by: FOP 1.0dev/name urlhttp://xml.apache.org/fop/dev/url imageimages/logo.jpg/image width138/width height31/height -/credit-- +/credit /credits /skinconfig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
