Re: FOP compliance in XML?
Thanks, Victor. I'll cross-check with what I have (Chuck Paussa's schema) and with my experience with FOP. Is there a keyword or something else we can use to query bugzilla about these limitations? Or maybe they are not all listed? Benoit Maisonny Victor Mote wrote: A couple of caveats: 1) The html version on our website is misleading because the color-coding is scrubbed out in our forrest conversion (I am trying to get that fixed). 2) The content applies to 0.20.5, not the main branch. 3) The content might not be entirely accurate. It came from some other documents, which I think were a bit out of date. It is really intended as a good starting place. In particular, I think there are places where we say that FOP is in compliance, but where there are some limitations that need to be cross-referenced. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16017] - Jpeg's and the PDF Serializer
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=16017. 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=16017 Jpeg's and the PDF Serializer --- Additional Comments From [EMAIL PROTECTED] 2003-01-14 12:21 --- The jpeg looks ok to me ijn fop0.20.5rc. Can you verify it in 0.20.5rc? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16017] - Jpeg's and the PDF Serializer
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=16017. 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=16017 Jpeg's and the PDF Serializer --- Additional Comments From [EMAIL PROTECTED] 2003-01-14 12:44 --- Arh... See this works Thanx. Err.. is the FOP0.20.5rc in the newest Cocoon dist? Just if others ask the same question. Shouldt i close the bug ? or...? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: bidi wiki
Victor Mote wrote: I just added a comment on your bidi wiki, in the Reordering the text section, regarding the line-by-line nature of reordering Middle-Eastern language text. This is something you no doubt already know, but was not clear to me until recently, and it may be helpful. Well done, Victor. I just forgot to mention it as it's obvious to me :) The comments might be expanded to a more general statement by someone who knows more. I have generalized it a little bit, I think it's enough for a while. We'll elaborate it further in implementation section. My problem is that I still doesn't have clear bidi implementation design in my mind, moreover the processing model as described in the spec sounds too quirky to me, all that fo-tree manipulation and directionality explicitiveness confuses me because I was grown on a principle that text must always be preserved in logical order up to the latest stage - rendering. And all bidi processing should be done by *renderer*, btw AWT renderer, which is bidi-aware on its own does render Hebrew ok even in the branch code! -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP logo
Jeremias Maerki wrote: Why don't we announce a competition. +1 +1 Set out some basic rules, provide somewhere to put the images and for others to make comments. The image could be any format but the final result should be SVG. There are some basic sizes, logo image, powered by size, others? Would that be a possibility? http://vote.sparklit.com/poll.spark/640946%22 sparklit.com rocks. So what about: - everyone can participate - no reward except for pride - winner image is donated to apache under ASL, but authorship is preserved - final result should be in SVG - reasonable size - everyone can vote, but only fop team picks out the winner - duration - one month - where to put images: o contestant's site o fop's site - vote.sparklit.com (free, probably ad-ware) - what else? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP compliance in XML?
Benoit Maisonny wrote: Is there a keyword or something else we can use to query bugzilla about these limitations? Or maybe they are not all listed? I've never made a comprehensive review of what is in Bugzilla. I don't know of any way to derive the list you seek. My goal has been to review the mailing lists each day distill this information from the questions problems that go by there, but I have not yet been able to implement that. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: bidi wiki
Oleg Tkachenko wrote: elaborate it further in implementation section. My problem is that I still doesn't have clear bidi implementation design in my mind, moreover the processing model as described in the spec sounds too quirky to me, all that fo-tree manipulation and directionality explicitiveness confuses me because I was grown on a principle that text must always be preserved in logical order up to the latest stage - rendering. And all bidi processing should be done by *renderer*, btw AWT renderer, which is bidi-aware on its own does render Hebrew ok even in the branch code! Wow -- I have never read through that section of the standard before. I am surprised that they require actually changing the FO tree. It also seems that this is another case where our layout-before-knowing-context model bites us. We don't really have a refinement stage in our model. The only other place where I have felt like I needed one is text-transform. Using the work that you did as a starting place, I was able to sneak text-transform functionality in as part of the FOText object constructor (this was in the branch, and I haven't had a chance to bring it over to the trunk). This was the /only/ place after seeing the input and before it was getting laid out in lines. The reason the refinement stage is important is because some of these things require a knowledge of the context. I implemented text-transform by looking at only preceding text in the same block, but was worried that we would find some aspect of text-transform that needed to know what came after -- if so, there is no clean way to handle it. It seems like this might fall into that same category. As far as whether reordering should get done at layout or rendering time, I think that the standard lumps these two concepts, distinct to us, into one super-concept that they call formatting. So (and I may be wrong) it seems that you are free to implement that in the renderers. If I understood the standard, we just need to slide the appropriate Unicode bidi codes into the text during the formatting stage that effectively implement the net effect all of the directionality information. I think you are right that any text reordering must be done by the renderers (or perhaps the RenderingContext that has been discussed in another thread). Not just AWT, but probably PDF, now or in the future, will handle the reordering. Its search routines need to have the text in logical order as well. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP logo
Hello! I have prepared free web poll at http://vote.sparklit.com/web_poll.spark/714566. I'm not sure about background...Comments? Anybody interested in admin rights - mail me. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP logo
Oleg Tkachenko wrote: Why don't we announce a competition. +1 +1 +1 - what else? It might be good to have a time window for submissions a separate time window for voting. If everybody went out and voted today, we would have a lot of extra votes for the moose that might not be there after the choices are all visible (just kidding -- I like our logo). Also, it would be good to state that everyone should vote only once (honor system). If you need a place to put the images, I'll be happy to put them on my site. Oleg, here is the URL for Bernd Brandstetter's submission the other day: http://outfitr.com/fop/logo/fop-parrot-logo.png Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/pdf PDFRoot.java PDFOutline.java
keiron 2003/01/14 11:55:20
Modified:src/org/apache/fop/pdf PDFRoot.java PDFOutline.java
Log:
setting for page mode, fixed some errors
Revision ChangesPath
1.13 +45 -9 xml-fop/src/org/apache/fop/pdf/PDFRoot.java
Index: PDFRoot.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFRoot.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- PDFRoot.java 11 Jan 2003 19:38:52 - 1.12
+++ PDFRoot.java 14 Jan 2003 19:55:20 - 1.13
@@ -13,6 +13,26 @@
public class PDFRoot extends PDFObject {
/**
+ * Use no page mode setting, default
+ */
+public static final int PAGEMODE_USENONE = 0;
+
+/**
+ * Use outlines page mode to show bookmarks
+ */
+public static final int PAGEMODE_USEOUTLINES = 1;
+
+/**
+ * Use thumbs page mode to show thumbnail images
+ */
+public static final int PAGEMODE_USETHUMBS = 2;
+
+/**
+ * Full screen page mode
+ */
+public static final int PAGEMODE_FULLSCREEN = 3;
+
+/**
* the /Pages object that is root of the Pages hierarchy
*/
protected PDFPages rootPages;
@@ -22,6 +42,8 @@
*/
private PDFOutline outline;
+private int pageMode = PAGEMODE_USENONE;
+
/**
* create a Root (/Catalog) object. NOTE: The PDFRoot
* object must be created before the PDF document is
@@ -38,13 +60,13 @@
}
/**
- * Before the root is written to the document stream,
- * make sure it's object number is set. Package-private access
- * only; outsiders should not be fiddling with this stuff.
- */
-/*void setNumber(int number) {
-this.number = number;
-}*/
+ * Set the page mode for the PDF document.
+ *
+ * @param mode the page mode
+ */
+public void setPageMode(int mode) {
+pageMode = mode;
+}
/**
* add a /Page object to the root /Pages object
@@ -95,8 +117,22 @@
if (outline != null) {
p.append( /Outlines + outline.referencePDF() + \n);
p.append( /PageMode /UseOutlines\n);
+} else {
+switch (pageMode) {
+case PAGEMODE_USEOUTLINES:
+p.append( /PageMode /UseOutlines\n);
+break;
+case PAGEMODE_USETHUMBS:
+p.append( /PageMode /UseThumbs\n);
+break;
+case PAGEMODE_FULLSCREEN:
+p.append( /PageMode /FullScreen\n);
+break;
+case PAGEMODE_USENONE:
+default:
+break;
+}
}
-p.append( /PageMode /FullScreen\n);
p.append( \nendobj\n);
return p.toString().getBytes();
}
1.6 +3 -3 xml-fop/src/org/apache/fop/pdf/PDFOutline.java
Index: PDFOutline.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFOutline.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- PDFOutline.java 11 Jan 2003 19:38:52 - 1.5
+++ PDFOutline.java 14 Jan 2003 19:55:20 - 1.6
@@ -52,7 +52,7 @@
* @param title the title of the outline entry (can only be null for root
Outlines obj)
* @param action the action for this outline
*/
-public PDFOutline(int number, String title, String action) {
+public PDFOutline(int number, String ti, String action) {
super(number);
subentries = new ArrayList();
count = 0;
@@ -61,7 +61,7 @@
next = null;
first = null;
last = null;
-title = title;
+title = ti;
actionRef = action;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Distributing jimi.jar
Did you know that the Cocoon guys have jimi.jar in their CVS? I wonder if that's correct and if yes, I think we should do it, too. Reading the licence I get the impression that redistribution of the jar is possible but not without restrictions. IANAL so who can we ask if distributing this jar is ok? I get the impression that things like that will be an everlasting problem. There should be a central source of information on licencing at Apache. A place where the gathered legal knowledge can be hammered in stone and be reused by other projects. Even the fact that we didn't include jimi.jar and Cocoon did gives me an uneasy feeling that the licence-sweep held at the XML project last year wasn't done 100% right. I'd like to escalate that topic again. What I think would be in the best interest of the Apache Foundation would be a central source of information where all projects and subprojects can get information on licencing. The following things would be very helpful: - Licence guidelines - A document describing the relationship of the APL to other licences. (what's compatible, what's not and why) - A list of approved products to be redistributable by Apache What are your thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Licensing confusion (was Re: Distributing jimi.jar)
- forwarding to incubator and licensing lists - - note: licensing is not open to all - Jeremias Maerki wrote: Did you know that the Cocoon guys have jimi.jar in their CVS? I wonder if that's correct and if yes, I think we should do it, too. Reading the licence I get the impression that redistribution of the jar is possible but not without restrictions. IANAL so who can we ask if distributing this jar is ok? I get the impression that things like that will be an everlasting problem. There should be a central source of information on licencing at Apache. A place where the gathered legal knowledge can be hammered in stone and be reused by other projects. Even the fact that we didn't include jimi.jar and Cocoon did gives me an uneasy feeling that the licence-sweep held at the XML project last year wasn't done 100% right. I'd like to escalate that topic again. What I think would be in the best interest of the Apache Foundation would be a central source of information where all projects and subprojects can get information on licencing. The following things would be very helpful: - Licence guidelines - A document describing the relationship of the APL to other licences. (what's compatible, what's not and why) - A list of approved products to be redistributable by Apache What are your thoughts? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Distributing jimi.jar
I think this is overdue! Most developer, like me, do not know a lot about the different Licences out in the wild. There must be a reliable Homepage were the Apache Project can build up on his own definition, about what is allowed and what is not. This should include of course information for the user of fop, in which way he is allowed to use and redistribute the software. Isn't the jai.jar (which would give fop great functionality!) not redistributet for the same reason? Best Regards Markus Schäffler Did you know that the Cocoon guys have jimi.jar in their CVS? I wonder if that's correct and if yes, I think we should do it, too. Reading the licence I get the impression that redistribution of the jar is possible but not without restrictions. IANAL so who can we ask if distributing this jar is ok? I get the impression that things like that will be an everlasting problem. There should be a central source of information on licencing at Apache. A place where the gathered legal knowledge can be hammered in stone and be reused by other projects. Even the fact that we didn't include jimi.jar and Cocoon did gives me an uneasy feeling that the licence-sweep held at the XML project last year wasn't done 100% right. I'd like to escalate that topic again. What I think would be in the best interest of the Apache Foundation would be a central source of information where all projects and subprojects can get information on licencing. The following things would be very helpful: - Licence guidelines - A document describing the relationship of the APL to other licences. (what's compatible, what's not and why) - A list of approved products to be redistributable by Apache What are your thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Thanks Markus Schäffler -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
