Re: Next release - when?
Sorry to be a little late but I'm -1 on merging product documentation with project documentation again. I found that VERY nice to have because it gives us a cleaner structure. For me, the most important thing is to be able to simplify release management which is still somewhat too work-intensive. I really like how Forrest did it (although I still haven't checked how. I think they do something with views) and they do publish versioned docs. I like keeping the difference between Trunk and the latest stable release especially since we don't do releases every two or three months. It produces less confusion if we add new features in Trunk for those who use the latest release. +1 to switching to Forrest 0.8. On 14.01.2008 06:17:45 The Web Maestro wrote: On Jan 12, 2008 8:42 AM, The Web Maestro [EMAIL PROTECTED] wrote: On Jan 11, 2008 2:28 AM, Vincent Hennebert wrote: Refactoring the website? I've already been told several times that it was difficult to find its way on it. Last time I mainly rephrased a few sentences and removed broken links, but didn't do much more. And I didn't even touch the 'Development' tab which is progressively becoming out-of-date. Should I add that this is not a trivial task and that I'll have no time for that in the next couple of months? :-P I'd be happy to help with the web site. It's not perfectly clear to me what else it needs, but I have some ideas. In a nutshell, 'Home' should include 'user' related general stuff (all the stuff it has, plus using FOP, upgrading, running, etc.--all the content from Version 0.94). The Develop should contain all that it has, plus any 'FOP Trunk' specific stuff. I don't what that is ATM... on first glance the nav for 'Version 0.94' and 'FOP Trunk' are identical nav (except V-0.94 has Release Notes, Changes Known Issues). I imagine a good start would be to remove all tabs except for 'Home' and 'Development' - 'Version 0.93' just goes away - 'Version Trunk' content moves to 'Home' - I think 'FOP 0.94' just goes away. I don't see anything different between the nav links in the 'FOP Trunk' and 'Version 0.94' tabs--if there is, that content should move to 'Development'. I'll run `diff` on the fop/0.94/ and fop/trunk/ directories to see what's different. If anyone has an specific ideas on what's different, that'd help greatly. We could retain the 'Home', 'Version xxx', 'FOP Trunk', 'Development' tab structure, but I think less tabs may be better now that we've retired 'Version 0.20.5', during which time, I believe the multiple tab structure was necessary. Here's my first stab at a refactored FOP site: http://people.apache.org/~clay/fop_refactored/ Of course, I'm open to suggestions. In a nutshell, here's what I did: - rm -R 0.93/ - rm -R 0.94/ - mv trunk/* ../ - modify site.xml - change links to /0.94/* /trunk/* to /* - check for broken links I'll likely need to do the above again when we're ready to deploy. Notice, I didn't do an `svn delete` on any of the above, since I'm hoping for feedback first. I'll likely do the SVN equivalents to the above when we're ready for primetime. If that time is now, I could do it fairly quickly. I'm also considering updating the Forrest build process to use Forrest 0.8 instead of Forrest 0.7. If anyone's interested, here're zip'd versions of the site.xml tabs.xml files: http://people.apache.org/~clay/fop_refactored/site.xml.zip http://people.apache.org/~clay/fop_refactored/tabs.xml.zip Web Maestro Clay -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet Jeremias Maerki
Re: Next release - when?
Hi, Jeremias Maerki wrote: On 14.01.2008 08:58:04 Max Berger wrote: Dear Fop Devs, I think we are mixing two ideas here: One idea (1) was to release 0.95rc, and then two weeks later 0.95 The other idea (2) is to release 0.95 and call it 0.95rc instead of 0.95beta. (1) I think makes sense. It would mean after releasing the rc there would be a short phase (2 weeks) where only bugfixed could be commited. This is a good idea anyways. +1 (2) The traditional dev steps are alpha - beta - final. Some companies use Release Candidate to make their beta-phase sound nicer. I strongly disagree of the use of this word without actually meaning it - as long as this is not a feature-complete version of fop 1.0 I'd vote -1 for calling it rc. I think we mean (1), at least I do. Yes that’s what I was meaning too, although 2 weeks seem rather short to me. I’d extend the testing phase to at least one month. And according to [1] we would name this release 0.95 beta, as RC is targetted to a smaller audience. At least that’s how I understand it. [1] http://apache.org/dev/release.html#release-typeso Btw: Other projects, such as GNOME and eclipse have a strong time-based release plan. Maybe this would be a good idea for the fop project as well? It would give users (and plugin developers) more certainty about whats going on. Well, nice in theory but that's only possible if there are enough resources. We have to do it based on available time and that's not really predictable in our case. Agreed. I seem to have seen somewhere on the website that we would try to make a new release about every 6 months. It’s not such a bad indication IMO. Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Namespaces for attributes in instream objects
Dear Fop-Devs, I've just recently encountered a possible bug in the jeuclid plugin for fop. A complete .fo file is added at the end of the mail. In this file there is a foreign math object: fo:instream-foreign-object mml:math mml:mstyle mathsize=6pt mml:mix/mml:mi /mml:mstyle /mml:math /fo:instream-foreign-object, which, as you can see, uses the mathsize attribute. HOWEVER, the attribute gets ignored, because it is in the default namespace, and only the attributes in the mml namespace are actually processed by the plugin. So the above needed to be fixed to: mml:mstyle mml:mathsize=6pt mml:mix/mml:mi /mml:mstyle to work properly. So here are my questions: - Is this indeed the expected behavior? It seems unintuitive. - If it is, should it be? Should the plugin not also process attributes from the default namespace? - If it is not, where do i need to start looking for the bug? Jeuclid completely ignores namespaces in attributes, so it is either in the fop/plugin interface, fop itself, or the xerces parser? Thanks Max --- ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:mml=http://www.w3.org/1998/Math/MathML; font-size=10pt fo:layout-master-set fo:simple-page-master master-name=page fo:region-body region-name=flow/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page fo:flow flow-name=flow fo:block Normal fo:instream-foreign-object mml:math mml:mix/mml:mi /mml:math /fo:instream-foreign-object, small fo:instream-foreign-object mml:math mml:mstyle mathsize=6pt mml:mix/mml:mi /mml:mstyle /mml:math /fo:instream-foreign-object, big fo:instream-foreign-object mml:math mml:mstyle mathsize=24pt mml:mix/mml:mi /mml:mstyle /mml:math /fo:instream-foreign-object /fo:block /fo:flow /fo:page-sequence /fo:root
Re: Namespaces for attributes in instream objects
I use attributes in the default namespace in Barcode4J and have no problems there. I've just updated my local JEuclid working copy and tried once again to build it or set it up in Eclipse but I failed. Once again. I have no nerves for Maven and won't waste one more second of my life on a Maven-enabled project that doesn't just build. Sorry, but I can't help if I can't debug locally. On 14.01.2008 14:23:59 Max Berger wrote: Dear Fop-Devs, I've just recently encountered a possible bug in the jeuclid plugin for fop. A complete .fo file is added at the end of the mail. In this file there is a foreign math object: fo:instream-foreign-object mml:math mml:mstyle mathsize=6pt mml:mix/mml:mi /mml:mstyle /mml:math /fo:instream-foreign-object, which, as you can see, uses the mathsize attribute. HOWEVER, the attribute gets ignored, because it is in the default namespace, and only the attributes in the mml namespace are actually processed by the plugin. So the above needed to be fixed to: mml:mstyle mml:mathsize=6pt mml:mix/mml:mi /mml:mstyle to work properly. So here are my questions: - Is this indeed the expected behavior? It seems unintuitive. - If it is, should it be? Should the plugin not also process attributes from the default namespace? - If it is not, where do i need to start looking for the bug? Jeuclid completely ignores namespaces in attributes, so it is either in the fop/plugin interface, fop itself, or the xerces parser? Thanks Max snip/ Jeremias Maerki
Re: Next release - when?
I'll spend some more time working on the 0.8 upgrade. I'll also look into implementing 'views' for the versioned docs. I guess things have changed enough between 0.93 0.94 so we really do need 0.93 (although when 0.95 is released we should be able to omit 0.94?)... If we're going to have releases around, should we put them under 'Versioned Docs' (like Forrest) or do they deserve their own tabs? Clay On 1/14/08, Vincent Hennebert [EMAIL PROTECTED] wrote: Hi Clay, Sorry I have to agree with Jeremias here, I think the 0.93, 0.94, Trunk tabs are ok. In fact the general structure of the website is more or less ok to me. But I think the following could be improved: - the skin looks a bit old now. Maybe upgrading to Forrest 0.8 (+1, BTW) will improve things but anyway some work is needed in this area I think. (Actually the Batik website doesn't look bad... ;-) ) At some point I guess we will need our own branding, rather than relying on a default stylesheet. - the behaviour of the menu on the left is a bit annoying: having to click on a sub-menu to unroll it is a pain. Every time you switch to another tab then switch back to the previous one, you have to unroll the menus again. That's confusing I think. Example: on the Home tab, click on 'Resources', then click on the 'Version 0.94' tab, then go back to the 'Home' tab: you have to re-click on 'Resources' to unroll it again. I guess there is a parameter to disable that, and have flat menus by default? - there should be a short 'news' sections on the home page, to show that the project is alive. Currently you have to click on 'Project' to unroll the menu, then on 'News'. That's two superfluous clicks ;-) We could leave older news in this section, and put the most recent ones on the home page. - many other pages could be reworked/updated/removed/merged, but the previous points are the most important to me. Jeremias Maerki wrote: Sorry to be a little late but I'm -1 on merging product documentation with project documentation again. I found that VERY nice to have because it gives us a cleaner structure. For me, the most important thing is to be able to simplify release management which is still somewhat too work-intensive. I really like how Forrest did it (although I still haven't checked how. I think they do something with views) and they do publish versioned docs. I like keeping the difference between Trunk and the latest stable release especially since we don't do releases every two or three months. It produces less confusion if we add new features in Trunk for those who use the latest release. +1 to switching to Forrest 0.8. snip/ Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting -- Sent from Gmail for mobile | mobile.google.com Regards, The Web Maestro -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
DO NOT REPLY [Bug 42845] - Printing error. Prints charater+1.
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=42845. 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=42845 --- Additional Comments From [EMAIL PROTECTED] 2008-01-14 07:29 --- Hi! Well, due to the fact that the problem occurs only very arbitrary the problem might affect a bigger number of people than you think. But nevertheless the problem is discussed in sseveral other groups. To give you an idea here some links http://www.adobeforums.com/webx/.3bbeb93b - this content has been extracted by myself http://www.adobeforums.com/webx/.3bc3a663 http://www.adobeforums.com/webx/.3bc2f70f http://www.hostingforum.ca/156897-garbled-output-character-shift-adobe-pdfs-via- citrix.html Of course it is not possible for me to rule out third party issues. All I can say is that the problem occurs only with documents generated by FOP. And I aggree as long as there is no way of reproducing the problem, it is quite hart (or maybe impossible) to track down the problem. Nevertheless in my opinion you should not ignore this error. Maybe there is a problem with the font identification mechanism inside the generated PDF documents. (In reply to comment #4) Unless you take the necessary steps to rule out the third-party APIs for being responsible for this and you supply concrete examples (or a guide) to reproduce the problem, there's really nothing we can do. There are most probably a lot of variables in here that we don't know of. You say it works with some printer drivers and not with others. That's an indication that FOP is not at fault. Furthermore: so many people are printing FOP-generated PDFs with Acrobat and don't have problems. You'd have to look more towards the end of the processing chain, i.e. between Acrobat and the operating system, where we can't help you. Unfortunately, Adobe usually leaves you in the rain when you run into problems and printer drivers are often the source of problems in that area. -- 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: Disable 900 penalty when not all cells have contributed in tables?
Thanks for all your feedbacks. Hearing no objections, I’ll then commit the change in the next days. Vincent Vincent Hennebert wrote: Hi, The title may be a little cryptic for those who aren’t familiar with the table layout code :-\ But basically it corresponds to the following: When a row starts at the bottom of a page, there may not be enough remaining room to allow every cell to put a part of its content: | Cell 1 | | - Page break --- | | This text doesn’t fit | | | on the previous page | Currently, a 900 penalty is assigned to such a break possibility, to avoid as much as possible this situation from occurring. However, it doesn’t completely prevent it, as we have seen recently on fop-users. My proposal is to forbid it, as anyway the output is so ugly that one would probably prefer some extra blank space at the bottom of the page instead. Is there anyone against me applying this change? Thanks, Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
DO NOT REPLY [Bug 44229] - Replacing GU in slot 0. Some content may not be painted.
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=44229. 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=44229 --- Additional Comments From [EMAIL PROTECTED] 2008-01-14 08:31 --- Created an attachment (id=21385) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=21385action=view) stylesheet causing the warnings -- 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.
DO NOT REPLY [Bug 42845] - Printing error. Prints charater+1.
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=42845. 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=42845 --- Additional Comments From [EMAIL PROTECTED] 2008-01-14 08:38 --- Ulrich, the links you provided clearly indicate that the problem must be in Acrobat Reader (or maybe in the Acrobat Reader/Printer Driver interaction). If a PDF file displays correctly on screen but prints wrong, how can FOP be the cause of that? Furthermore, people report that opening the same file again usually makes the problem go away. The only thing we can potentially do in FOP is add an FAQ entry giving pointers about the problem. But otherwise, it's completely up to Adobe (or you switching to a different PDF viewer). Maybe something in FOP causes this bug in Acrobat to appear but without Adobe making a statement what exactly that is (if there is something in the first place), there's nothing we can do. BTW, are you in a Citrix environment? I've seen all sorts of weird behaviour around printing on Citrix clients in my career. Sorry, but I have no idea how I could help here. Let's leave this open for the moment. If we get more information from Adobe, maybe we can do something in terms of documentation. -- 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.
DO NOT REPLY [Bug 44229] - Replacing GU in slot 0. Some content may not be painted.
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=44229. 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=44229 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2008-01-14 08:51 --- That's a regression from 0.93 to 0.94 that has been fixed in FOP Trunk. I think you can safely ignore the warning as long as your work with 0.94. The warning messages are clearly wrong and the FO produced by your stylesheet is just fine. -- 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.
DO NOT REPLY [Bug 44229] - Replacing GU in slot 0. Some content may not be painted.
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=44229. 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=44229 --- Additional Comments From [EMAIL PROTECTED] 2008-01-14 08:43 --- Created an attachment (id=21388) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=21388action=view) xml file to reproduce the problem -- 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: Next release - when?
On Jan 10, 2008, at 18:05, Jeremias Maerki wrote: Apologies for the rather late reply: I think we should start to plan the next release. How about targeting the end of February or beginning of March? Good idea. Without much thinking, the following items are on the table: - Stabilizing tables. - Stabilizing the image package once I've merged the brach into trunk. - Verifying the AFP output works correctly. What else? Can't really think of anything pressing, so I'm going to leave this open for now. I agree with the intention of calling it a 'Release Candidate' (as we have already dropped the Beta-tag when 0.93 was released...), and a period of +/- 1 month before making the final 0.95 release, as Vincent suggested, also sounds pretty good to me. Cheers Andreas
Re: Namespaces for attributes in instream objects
On Jan 14, 2008, at 14:23, Max Berger wrote: Hi Max, I've just recently encountered a possible bug in the jeuclid plugin for fop. Just checking (would make tracking it a bit easier): Do you have any idea if this ever worked, and if yes, when this stopped working? (or: Do you remember having used the MathML extension and not running into the issue?) Would be nice to know, but no matter if you don't have the answer. More inline below... A complete .fo file is added at the end of the mail. In this file there is a foreign math object: fo:instream-foreign-object mml:math mml:mstyle mathsize=6pt mml:mix/mml:mi /mml:mstyle /mml:math /fo:instream-foreign-object, which, as you can see, uses the mathsize attribute. HOWEVER, the attribute gets ignored, because it is in the default namespace, and only the attributes in the mml namespace are actually processed by the plugin. So the above needed to be fixed to: mml:mstyle mml:mathsize=6pt mml:mix/mml:mi /mml:mstyle to work properly. So here are my questions: - Is this indeed the expected behavior? It seems unintuitive. For FO, we assume all attributes in the default namespace to be XSL- FO properties, so I think this is unexpected... :/ - If it is, should it be? Should the plugin not also process attributes from the default namespace? I would definitely say so. - If it is not, where do i need to start looking for the bug? Jeuclid completely ignores namespaces in attributes, so it is either in the fop/plugin interface, fop itself, or the xerces parser? I can't quite put my finger on it yet, but if I were to start looking, I'd try placing a breakpoint in the private org.apache.fop.fo.XMLObj#setAttributes(). See what happens there. Judging from the code, the attributes without a prefix are added to the node via the generic org.w3c.dom.Element#setAttribute(). Maybe problems with the (writable) DOM implementation? Or does the MathML extension not use the 'XMLObj.element' member, or ? HTH! Andreas
