Outdated docs?
I can't find the config file mentioned below. What is the new location of this file? > Using Cocoon sitemap execution logger > > In main/webapp/WEB-INF/xconf/forrest-core.xconf search for "sitemap > execution" and uncomment the component. For each sitemap component > that is executed, a message will go to WEB-INF/logs/debug.log Extract from http://forrest.apache.org/docs_0_80/howto/howto-dev.html#debug-cocoon-profiler Regards, Ferdinand Soethe --- Fischerzug 3a 21522 Hohnstorf Germany ph +4139/696244 mob +1772507870 Tax-ID.: 2326 02613903524 http://soethe.net/ferdinandSoethe.vcf
Re: Addressing FOR-652 CSS cleanup (was Re: [jira] Subscription: FOR-open-with-patch)
Am 22.04.2008 um 11:32 schrieb Thorsten Scherler: ... This is way too verbose and should go away in a new version. IMO the @id does not provide any valuable information therefore it should be striped. If the @id is needed for the expanding js menu is needed then the menu should be rewritten. I agree. Keep in mind that bigger sites will have a lot of these entries within each and every page. Having really long names will significantly increase page size. The id="leftbar" should be renamed to something more general. Hmmm. I think this really depends. If this div is the container for the box on the left side of the page, the name is correct and clear. If is was the container for the menu it should be changed. But since the menu is contained in nav-section. Why change? Regards, Ferdinand Soethe
Re: PDF output and Dispatcher
Gav schrieb: Hi All, This was going to be an email about how PDF was not working with Dispatcher, more accurately that it did not work using Pelt Theme or any theme that does not over-ride FO from /common/ . Usually, when I copy over Pelt Theme for over-riding to my project, I also copy over /common/ just in case I need to change any of that too. This was my downfall here, because changes made to /common/fo recently did not get updated in my local project, so broke PDF output. I then spent 1/2 hr fault-finding and correcting errors in layout-master-set.ft only to find that this had already been done in whiteboard. So, a doh! moment for me, and a heads-up to anyone else that has local copies of themes/common/* , remember to update them, better still, try not to change anything in common, copy it to /pelt/ and change it there instead. Gav... This is a really interesting observation since I thought we had moved all fo-transformations from core (common-directories) to the plugin. Not sure how changing anything in common could still make a difference. Are you sure you have updated the pdf-plugin? Ferdinand
Re: Changes to xi:include handling
David Crossley wrote: There was recent discussion about XInclude in our archives (IIRC forrest user list). There was a suggestion to enable it by default in our xdocs dtd. No-one followed through. Yeah. Is read that and some others. But none of it worked. Also did you try using the "cocoon://" protocol. Now I did. And it works like a charm. Thank you kindly. Best regards, Ferdinand Soethe
Changes to xi:include handling
I have some trouble using xi:include with head. When I last used it it 0.7 something like xmlns:xi="http://www.w3.org/2001/XInclude"/> would include a document from the same directory that the including file is in. Now when I use this in head I get an error Resource not found: file:/C:/forrest/head/main/webapp/indextest.xml meaning the file is looked for in the forrest programm directory. Does anybody know why this was changed or how I can get my convenient relative addressing back? Or at least how to include the current directory w/o hardcoding it? Thanx, Ferdinand
Re: [jira] Updated: (FOR-1072) [PATCH] Bugfixes and improvements for PDF output plugin
BTW, where can I find this "forrest-sample-2" so I could run it myself? I've only run "forrest seed" now. run "build test" in main to test all the test cases. test sites will then be created in forrest/build directory. Best regards, Ferdinand Soethe
Re: [jira] Updated: (FOR-1072) [PATCH] Bugfixes and improvements for PDF output plugin
Thanks Jeremias, some great improvements as far as I can see. Especially the keep together for notes. I have tested the patch but not committed it because it broke trunk. Here is the list of problems Forrest reported: ^samples-b/ ^samples-c/ ^samples-c/subdir/ ^samples-c/showonlywhenselected/ ^pluginDocs/plugins_0_90/ * [1/35][35/41] 7.657s 13.7Kb linkmap.html * [3/36][3/31]1.296s 8.6Kb samples-b/static.html * [4/35][0/0] 2.829s 106.1Kb samples-b/static.pdf * [5/39][5/37]0.75s 26.7Kb samples-b/sample.html WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. table (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. block (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. list-item-body (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. list-item (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. list-block (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. block (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. block (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. block (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. flow (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. page-sequence (http://www.w3.org/1999/XSL/Format) WARN - Mismatch: table-header (http://www.w3.org/1999/XSL/Format) vs. root (http://www.w3.org/1999/XSL/Format) X [0] samples-b/sample.pdf BROKEN: Error(Unknown location): fo:table-header is missing child elements. Required Content Model: marker* (table-row+|table-cell+) * [8/37][1/24]0.812s 7.2Kb samples-c/i18n.html * [9/36][0/0] 0.344s 105.7Kb samples-c/i18n.pdf * [10/36] [1/31]0.609s 7.9Kb samples-b/usemap.html * [11/35] [0/0] 0.532s 106.8Kb samples-b/usemap.pdf * [12/35] [1/25]0.656s 6.9Kb samples-c/showonlywhenselected/page1.html * [13/34] [0/0] 0.219s 104.7Kb samples-c/showonlywhenselected/page1.pdf * [15/32] [0/0] 11.157s 7.4Kb images/group.png * [16/33] [2/31]1.156s 10.8Kb samples-b/embedded_html.html * [17/36] [4/28]0.734s 8.9Kb samples-c/index.html ^samples-b/site:index * [19/34] [0/2] 0.047s 3.6Kb samples-b/embedded_html.xml WARN - Bookmarks: Unresolved id reference "__toc__" found. WARN - Bookmark with IDRef "__toc__" has a null PageViewport. * [20/33] [0/0] 0.75s 105.0Kb linkmap.pdf * [21/32] [0/0] 0.0s 951b/images/usemap.gif * [22/33] [2/31]0.343s 7.8Kb samples-b/ascii-art.html * [23/32] [0/0] 0.954s 107.7Kb samples-b/ascii-art.pdf * [24/31] [0/0] 0.234s 8.3Kb images/project.png * [26/30] [1/20]2.0s 59.4Kb pluginDocs/plugins_0_90/index.html ^pluginDocs/plugins_0_90/ * [27/30] [1/40]0.672s 10.3Kb index.html * [28/29] [0/0] 0.25s 105.4Kb index.pdf * [29/29] [1/25]0.609s 7.0Kb samples-c/showonlywhenselected/page2.html ^samples-b/ext:forrest * [30/28] [0/9] 0.11s 19.2Kb samples-b/sample.xml * [31/27] [0/0] 0.25s 10.3Kb * [33/25] [0/0] 0.375s 3.2Kb skin/basic.css * [34/25] [1/34]0.641s 10.3Kb samples-b/index.html * [35/25] [1/27]0.672s 7.2Kb samples-c/subdir/index.html * [36/37] [13/13] 0.343s 13.4Kb skin/screen.css * [38/35] [0/0] 0.234s 319bskin/images/rc-b-r-15-1body-2menu-3menu.png * [39/34] [0/0] 0.079s 209b skin/images/rc-t-l-5-1header-2tab-selected-3tab-selected.png * [40/33] [0/0] 0.046s 200b skin/images/rc-b-r-5-1header-2tab-selected-3tab-selected.png * [41/32] [0/0] 0.047s 214b skin/images/rc-t-r-5-1header-2tab-unselected-3tab-unselected.png * [42/31] [0/0] 0.047s 199b skin/images/rc-t-l-5-1header-2searchbox-3searchbox.png * [44/30] [1/20]0.609s 5.5Kb samples-a/index.html * [45/29] [0/0] 0.25s 105.0Kb samples-a/index.pdf * [46/28] [0/0] 0.047s 214b skin/images/rc-t-r-5-1header-2searchbox-3searchbox.png * [47/27] [0/0] 0.062s 1.3Kb skin/print.css * [48/26] [0/0] 0.047s 390bskin/images/rc-t-r-15-1body-2menu-3menu.png ^pluginDocs/plugins_0_90/ ^samples-b/ * [50/37] [13/49] 0.812s 30.9Kb samples-b/linking.html * [51/36] [0/0] 0.281s 1
Moving from skinconfig w/o breaking old Forrests
Would it be an option to add a property like UseNewPropertySystem that defaults to "no" if not set but is set to "yes" in the default properties from 0.9 on? That way we could move properties for the 0.4 version of pdf-plugin (and most others including core) right away. Since we need a lot more properties for pdf soon (as Johannes already documented earlier on, the alternative would be for users of older Forrests to add all these new settings as soon as they upgrade. Best regards, Ferdinand Soethe
Re: RT: Storage of Properties
er both? Yeah, why not. Can we change this right away before writing the documentation? Cool! Can I also get a list where the source of a setting is shown? How about adding the source of a setting as a third element? Yeah would be possible, what would be the benefit? The benefit would be the easy of tracking down where a property originated. Rather than checking perhaps a dozent or more properties files (if all the places are used). Perfect, hopefully somebody can find the time to document the outcoming of the thread. I volunteer to document the properties mechanism. Best regards, Ferdinand Soethe
Re: dispatcher contracts default properties (was Re: RT: Storage of Properties)
I need to learn more about structurer and dispatcher quickly to understand what you are saying but I agree to having default properties for contracts. Best regards, Ferdinand Soethe Thorsten Scherler wrote: ... Meaning each contract would have publish his own original properties No, contracts do not have default properties. They are coming from the structurer. Actually due to the nature of contracts that is very much possible and actually will save some processing time if it is practice. Imaging e.g. the branding-css-links contract, right now we always await an input but since this is a common contract it could provide his default properties. Instead of: we can do something like: and in the default structurer we will have: since we do not override nothing we will save some processing (which is very good). salu2
Re: RT: Storage of Properties
own? How about adding the source of a setting as a third element? Meaning: Insert the plugin-properties before the Forrest core properties, the insert the skins properties before the plugin properties. Actually for me skinconf/contract properties are apart from other properties since they are normally view dependent. Can the input plugin offer another pipeline for that? And also for CSS-Aggregation while we are at it ... Validation is tricky. Ideal would be that every source of properties publishes a realx-NG grammar-module in a way that all modules can be aggregated in a pipeline. IMO properties files should be flat. Like forrest.properties/~.xml and the standard java properties. This way we have only one dtd/ng schema and the validation is trivial. IMHO keeping validation trivial only saves work on the part of the author of new properties while it increases the risk of errors for all users and programmers. As I mentioned above, adding true validation of property name and value avoids configuration errors by the user and makes it very clear to any programmer using the property what values he or she has to deal with. Thanks Thorsten for taking the time. Now I can actually understand what you are trying to so and help move those pdf-specific settings into the plugin-properties. Best regards, Ferdinand Soethe
RT: Storage of Properties
Let me know if this is completely off track, but I'm thinking about how best to store properties with so many different components needing to store and access properties. Here are some of my thoughts: Who needs to be able to create properties? = - Core creates properties, sets default values, allows overriding these values in a project = properties for very basic settings such jetty port, plugins used = project properties copyright, logos etc - Skins and/or Dispatcher-Components (I'd like to keep at least one skin - which may be a dispatcher configuration - as a very easy to use and manipulate default) create properties, set default values, allow overriding these values in a project = properties for look and feel interface layout, css, colors etc (Note: Even if we completely switch to dispatcher, I'd like to keep functionalities of the skin to show ore hide components or place them differently, even though this could also be accomplished with dispatcher programming) = properties that add functionality or data to the project as whole a dispatcher file-change-date-component stores the desired date-format - Plugins create properties, set default values, allow overriding these values in a project = plugin-dependant properties page format and other settings specific to pdf-generation = specific css to be used when generating html from an input-plugin Each input-plugin could tag there input with ids or classes and influence final formatting by offering a css-block to be inserted at the end of the Forrest css and before user css-files. What needs to be considered/what is desirable === ** Overlaps ** Many properties will be used and might even be set by different components. For example the pdf-plugin might come with a basic set of properties and defaults. But a skin might also offer defaults for pdf-output matching the skins specific style. On the other hand, the pdf-plugin will probably need to read some core properties to generate the copyright footer. ** Validation ** The ability to validate a properties-storage should be kept while the process of extending the property set in plugins or skins should be simplified. Blocks of included data that hinder validation (such as extra-css in skinconfig) should be avoided. Grammatically different information like css or xml-properties should be kept separate. ** Clear hierarchical structure and inheritance ** I'd much prefer inheritance to the current need of copying new properties into existing project files. New properties should automatically become available to all projects and entries in project-files would only be required if I wanted to set the property different from the default. A clear hierarchie should make it easy where to look. In order of decreasing priority project properties > skin/dispatcher properties > plugin defaults > Forrest defaults This also means that a skin can, but doesn't need to set anything for pdf-generation if it didn't want to change anything. Technical implementation = How about building a pipeline that prepends the basic Forrest properties with xml-data from configuration files on a higher level of priority. Meaning: Insert the plugin-properties before the Forrest core properties, the insert the skins properties before the plugin properties. This way it is technically very simple to catch the property with the highest priority but there is also the option to address other levels if needed. What's more, a simply call of that pipeline will show you the complete configuration in you browser and (if the pipeline aggregation inserts useful comments) you can see right away where a certain property came from. Validation is tricky. Ideal would be that every source of properties publishes a realx-NG grammar-module in a way that all modules can be aggregated in a pipeline. This way the modules can be used to validate properties at the source but also to validate a single common properties-file for the project. wdyt Ferdinand
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Since Jeremias is about to release fop 0.95 with yet more significant improvements, I amend my proposal as follows Ferdinand Soethe wrote: OK, so I'll wait for Johannes to finish his tests, fix what needs to be fixed then - copy the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8 - tag this state - then remove the libs from the plugin update fop to 0.95 and publish it as 0.4 dev requiring Forrest 0.9. P.S.: Jeremias said that this update only requires an update of the lib itself. Wrapper and all the rest remain the same. Best regards, Ferdinand Soethe
Re: [jira] Closed: (FOR-635) images not reliably reproduced in PDFs
Thorsten Scherler (JIRA) wrote: After the update to FOP 0.94 it is possible to use any protocol that is known to cocoon. This allowed to resolve the images via cocoon sitemap and drop the workaround that relied on the file system. Phantastic fix. Thanks, Thorsten! I would have never believed the solution was so close. Best regards, Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
David Crossley wrote: Ferdinand Soethe wrote: OK, so I'll wait for Johannes to finish his tests, fix what needs to be fixed then - copy the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8 And deploy/release it before moving on with code. yes, of course. - the create a branch pdf_plugin_03 Why? We haven't created a branch for any other plugin. Don't branch until we really need to. This was just to have the option of updating and releasing the plugin easily. It would be better to get moving with core 0.9 release. From my own experience I think that people will not always be able to follow us to a new release even if it was released soon. That's why I wanted to keep the option of updating the plugin for 0.8 Tagging the trunk is a good idea. We should add that to our plugin development procedure howto doc. Does tagging mean that we mark the release where 0.3 changes to 0.4 and would be able to branch from there easily one there are updates to the stylesheets? Best regards, Ferdinand Soethe
Re: [fo] Overflow bug in footerinfo.xsl
This problem was fixed by adding a height attribute. You might have to increase the height. See rev 627102 Best regards, Ferdinand Soethe Thorsten Scherler wrote: Hi all, I think I found a bug in footerinfo.xsl. In a fresh site add in skinconf (to ): Built with Apache Forrest http://forrest.apache.org/ Then watch the system out for: WARN - Part/page 0 overflows the available area in block-progression dimension. (fo:block-container, "Built with Apache Forrest, http://forrest.apache.org/";) Any idea how to fix this? salu2
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
OK, so I'll wait for Johannes to finish his tests, fix what needs to be fixed then - copy the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8 - the create a branch pdf_plugin_03 - then remove the libs from the plugin and publish it as 0.4 requiring Forrest 0.9. Best regards, Ferdinand Soethe
Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Thorsten Scherler wrote: On Mon, 2008-02-18 at 11:44 +, Ross Gardler wrote: Ferdinand Soethe wrote: The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. I must have missed that. Why were they moved back in? I think there was a misunderstanding. commons-io-1.3.1.jar -> should go into the plugin (because other code does not seem to need it) commons-logging-1.1.1.jar -> tricky since in 08 we have commons-logging-1.0.4.jar xmlgraphics-commons-1.2.jar -> not in 0.8 but needed by the plugin (should go into the plugin) No misunderstanding as far as I can tell. In the message http://marc.info/?l=forrest-dev&w=2&r=1&s=r618371&q=b you wrote That should not include common libs: [...] The following needs to be in core: Removed: forrest/branches/UpdateFOPto094/lib/core/commons-io-1.3.1.jar forrest/branches/UpdateFOPto094/lib/core/commons-logging-1.1.1.jar forrest/branches/UpdateFOPto094/lib/core/xmlgraphics-commons-1.2.jar and so I moved these libs back into core. And I think they should remain there now because _current common use_ is not really a useful criterion for placement of these libs. Somewhere along that road we'd start moving libs back into core when the next plugin requires them. Your earlier approach makes a lot more sense to me. Place all libs that could be of a common use in lib/core right away. IMO the plugin should work in 0.8 if the libs go back. We can release the plugin in version 0.3 (compatible with 0.8) and then raise the version to 0.4. So I propose to _copy_ the missing libs into the plugin, publish it as 0.3 requiring Forrest 0.8, then remove the libs from the plugin and publish it as 0.4 requiring Forrest 0.9. The only weak spot in proceeding like this is the difficulty of doing bugfixes (which are certainly to be expected) in the 0.3 version. Ross: Is there really no way of maintaining two versions of a plugins sources in our svn? We'd really need it in this case! Best regards, Ferdinand Soethe
Re: Please don't top post - (Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
I guess Ross was referring to me. Had to look up "top post" to know that he was referring to excessive quoting. And yes, I did. Was in a hurry and didn't clean up. Sorry! Add it to the sentence for merging my branch and temporarily breaking trunk assuming lazy consensus. Asche auf mein Haupt (what ever that is in English), Ferdinand Johannes Schaefer wrote: and whom ... me?! might be Ferdinand, see below
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
It did not seem to do any harm when I first tested it with head. Even the duplicate libs caused no problems as far as I could tell. I agree, that might be a nice solution for 0.8 users and since we'd update the plugin to 0.9 dependant right away, it would really only be a short term solution. wdot? Best regards, Ferdinand Soethe Johannes Schaefer wrote: would it do any harm to deliver the libs twice? i.e. include in the 0.8 plugin (throw out for the later versions) and in core? I haven't had the time to test with 0.8, yet :-( Johannes Ferdinand Soethe schrieb: The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. Because of this, the plugin will only work with 0.8 if 0.8 gets patched. What I haven't tested so far is if 0.8 will work with a locally deployed plugin that is marked for 0.9? Or would somebody wanting to use the new plugin with 0.8 also have to patch the ? Does anybody know or can anybody suggest a better solution? Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote: ... Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! I'm not against breaking the dependency. I'm only against doing it in 0.3 PDF plugin, released for Forrest 0.8, without warning or good reason. Hmm, does the new plugin work in 0.8? If so can we not release it now and after this raise the version to 0.4 which depends on 0.9. This would allow to incorporate the new properties system and get rid of duplicate code in the dispatcher. wdyt? salu2
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
The pdf-plugin will not work with 0.8 as is because it was decided to move critical libs from the plugin back into core. Because of this, the plugin will only work with 0.8 if 0.8 gets patched. What I haven't tested so far is if 0.8 will work with a locally deployed plugin that is marked for 0.9? Or would somebody wanting to use the new plugin with 0.8 also have to patch the value="0.8"/>? Does anybody know or can anybody suggest a better solution? Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote: ... Why are we using skinconf for core plugins? The only plugin that should use skinconf is a skin plugin (if it would exist)! I'm not against breaking the dependency. I'm only against doing it in 0.3 PDF plugin, released for Forrest 0.8, without warning or good reason. Hmm, does the new plugin work in 0.8? If so can we not release it now and after this raise the version to 0.4 which depends on 0.9. This would allow to incorporate the new properties system and get rid of duplicate code in the dispatcher. wdyt? salu2
Re: FOP94: BuildTest fails with Dispatcher
Great! Now we don't have to maintain two versions of this code. Thanks. Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Sun, 2008-02-17 at 09:49 +0100, Ferdinand Soethe wrote: Since the dispatcher test is still breaking trunk, I have now fixed some of the problems with fo used in the dispatcher plugin. Further tests unfortunately become impossible because forrest crashed with the message Exception in thread "main" java.lang.OutOfMemoryError: Java heap space. I fixed this by capsulizing the xsl methods in different helper stylesheet which we can import from the different dispatcher contracts. This reduce the maintenance since we only maintain them in one place (the pdf plugin). The problem still remains that the plugins use two different properties system which forces the dispatcher to maintain some custom code (which it is a pity). There are still a lot of warnings I need to look into but it was getting too late last night and seeing forrest build successful I hit the bed. Next steps is to fix the remaining warnings in the dispatcher and move the dispatcher fo related resources to the pdf plugin as well. salu2
Re: FOP94: BuildTest fails with Dispatcher
Since the dispatcher test is still breaking trunk, I have now fixed some of the problems with fo used in the dispatcher plugin. Further tests unfortunately become impossible because forrest crashed with the message Exception in thread "main" java.lang.OutOfMemoryError: Java heap space. If trunk remains broken, can we perhaps take the test involving the whiteboard plugin (dispatcher) out of the standarf build test? Best regards, Ferdinand Soethe Ferdinand Soethe wrote: Thorsten Scherler wrote: The FOP94 should provide this contracts directly, this way we can remove them from the core themes. I'd appreciate if you could contribute this ideally using the stylesheets already in the plugin. Is that possible? Best regards, Ferdinand Soethe
Re: svn commit: r628164 - /forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
jeje, like Jeremias explains the new fop is able to resolve special protocols like cocoon:// (I tested on the old one and it does not work there). This solves the problem I guess for most if not all image links since we can use cocoon pipelines to generate the image. some right away, the others once we changed the pipelines, I guess. Which are the images that fail, because this should actually fix all images? If not that can mean that we have another piece of code that is changing the image linking (or the when test are matching). In the skinned site ERROR - Image not available: C:\forrest\fop94\build\test_skinned_site/src/documentation/resources/images///icon-e.png ERROR - Image not available: C:\forrest\fop94\build\test_skinned_site/src/documentation/resources/images///ellipse-2.png ERROR - Image not available: cocoon://ellipse.png ERROR - Image not available: cocoon://cocoon-pyramid.png ERROR - Image not available: cocoon://icon-d.png * [24/54] [0/0] 1.203s 143.4Kb samples1/linking.pdf ERROR - Image not available: C:\forrest\fop94\build\test_skinned_site/src/documentation/resources/images///usemap.gif * [63/27] [0/0] 0.313s 105.3Kb samples1/usemap.pdf ERROR - Image not available: cocoon://cocoon-pyramid.png * [67/24] [0/0] 0.125s 104.9Kb samples1/ascii-art.pdf Thanks for helping on this. Hmmm. That is strange. I just reverted my merger thinking that I had broken trunk. But it is still broken. Did I do something wrong reverting changes from 628175? Btw. Do you know what broke trunk. Can I re-merge now that we know that trunk was broken before? Best regards, Ferdinand Soethe
Re: svn commit: r628164 - /forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
jeje, like Jeremias explains the new fop is able to resolve special protocols like cocoon:// (I tested on the old one and it does not work there). This solves the problem I guess for most if not all image links since we can use cocoon pipelines to generate the image. some right away, the others once we changed the pipelines, I guess. Which are the images that fail, because this should actually fix all images? If not that can mean that we have another piece of code that is changing the image linking (or the when test are matching). In the skinned site ERROR - Image not available: C:\forrest\fop94\build\test_skinned_site/src/documentation/resources/images///icon-e.png ERROR - Image not available: C:\forrest\fop94\build\test_skinned_site/src/documentation/resources/images///ellipse-2.png ERROR - Image not available: cocoon://ellipse.png ERROR - Image not available: cocoon://cocoon-pyramid.png ERROR - Image not available: cocoon://icon-d.png * [24/54] [0/0] 1.203s 143.4Kb samples1/linking.pdf ERROR - Image not available: C:\forrest\fop94\build\test_skinned_site/src/documentation/resources/images///usemap.gif * [63/27] [0/0] 0.313s 105.3Kb samples1/usemap.pdf ERROR - Image not available: cocoon://cocoon-pyramid.png * [67/24] [0/0] 0.125s 104.9Kb samples1/ascii-art.pdf Thanks for helping on this. Best regards, Ferdinand Soethe
Re: svn commit: r628187 [1/3] - in /forrest/trunk: lib/core/ main/webapp/ main/webapp/resources/stylesheets/ main/webapp/skins/common/xslt/fo/ plugins/org.apache.forrest.plugin.output.pdf/ plugins/org
I still don't understand why the revert did not work, but at least I know what broke trunk. My fault, I misunderstood the process of merging and did not merge all changes to trunk into my branch before merging branch back into trunk. Will fix that with a new merge this weekend. Best regards, Ferdinand Soethe Ferdinand Soethe wrote: Hmmm. That is strange. I just reverted my merger thinking that I had broken trunk. But it is still broken. Did I do something wrong reverting changes from 628175? Best regards, Ferdinand Soethe
Re: svn commit: r628187 [1/3] - in /forrest/trunk: lib/core/ main/webapp/ main/webapp/resources/stylesheets/ main/webapp/skins/common/xslt/fo/ plugins/org.apache.forrest.plugin.output.pdf/ plugins/org
Hmmm. That is strange. I just reverted my merger thinking that I had broken trunk. But it is still broken. Did I do something wrong reverting changes from 628175? Best regards, Ferdinand Soethe
Re: svn commit: r628164 - /forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
After some more testing I found that most of the broken image problems are not new but never showed because old FOP did not report them. Running our current test sites with Forrest 0.8 I found many of the same images missing in the pdf that are reported to be missing now. The fix at least solves the problem in committed.xml. Why it does is completely beyond me. Best regards, Ferdinand Soethe [EMAIL PROTECTED] wrote: Author: ferdinand Date: Fri Feb 15 12:29:05 2008 New Revision: 628164 URL: http://svn.apache.org/viewvc?rev=628164&view=rev Log: Changed image handling to solve problems with generated images and fop. Some improvement but not a complete solution. Modified: forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl Modified: forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl URL: http://svn.apache.org/viewvc/forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl?rev=628164&r1=628163&r2=628164&view=diff == --- forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl (original) +++ forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl Fri Feb 15 12:29:05 2008 @@ -1069,8 +1069,8 @@ - + cocoon://
Merge Fop94 now
I think we are ready to merge fop94 now. Several bugs in documents and stylesheets have been fixed. Build test for site-author and seed side passed without critical errors. The remaining problem of some broken images will not break trunk and probably requires some more input from the community. Build errors in the dispatcher still to be solved but since dispatcher is still in whiteboard this seems acceptable. wdyt?
Re: FOP94: BuildTest fails with Dispatcher
Thorsten Scherler wrote: The FOP94 should provide this contracts directly, this way we can remove them from the core themes. I'd appreciate if you could contribute this ideally using the stylesheets already in the plugin. Is that possible? Best regards, Ferdinand Soethe
FOP94: BuildTest fails with Dispatcher
I just ran the build test. Site-author and seed site are running smoothly except for the problems locating some image types. But the third test (Testing seeded dispatcher site ...) is still showing problems that suggest that it is using the old style sheet for document-2-fo-transformation. Any ideas how to fix that? Best regards, Ferdinand Soethe
Re: Problem with fop94 locating an aart-image
Thanks Thorsten and Jeremias for your comments. But now I'm really lost. Can anybody who understands this perhaps suggest a solution to this problem that is reasonable easy to implement and not a hack? Best regards, Ferdinand Soethe
Problem with fop94 locating an aart-image
I'm currently testing site-author with fop94 and came across this strange problem that in rendering /committed.html the aart-image committed-1.aart (located in xdocs, being called as committed-1.png) renders fine in html but causes this error in rendering fop. ERROR - Image not available: C:\forrest\fop94\site-author/./content/xdocs/committed-1.png Since I remembered fop needing images to be in the content/resources/images directory I tried moving the aart-file there but that didn't fix the problem. Any ideas what to do? Thanks, Ferdinand
Re: svn commit: r627063 - /forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl
Thorsten Scherler wrote: On Tue, 2008-02-12 at 19:52 +, [EMAIL PROTECTED] wrote: > Author: ferdinand > Date: Tue Feb 12 11:52:32 2008 > New Revision: 627063 > > URL: http://svn.apache.org/viewvc?rev=627063&view=rev > Log: > Fixed problems of id-attributes not being copied in all elements and missing for reference. > > Modified: > forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl > > Modified: forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl > URL: http://svn.apache.org/viewvc/forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl?rev=627063&r1=627062&r2=627063&view=diff > == > --- forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl (original) > +++ forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/document-to-fo.xsl Tue Feb 12 11:52:32 2008 > @@ -468,6 +468,7 @@ >match="notice"> > +id="[EMAIL PROTECTED]" The ugly side effect is that if no @id is present the above results in To prevent this you could do: You do it later on in this commit: ... > @@ -1000,16 +1011,10 @@ > match="figure|img"> >text-align="center"> > + > > name="insertPageBreaks" /> > - -test="normalize-space(@id)!=''"> > - -name="id"> > - -select="@id" /> > - > - > + > I can remember that having empty @id had caused me some trouble in the past. salu2 Thanks Thorsten, I will fix that. Best regards, Ferdinand Soethe
Re: pdf-plugin with fop .94 - can sbdy please help?
David Crossley wrote: Ferdinand Soethe wrote: Actually I regret having moved them back. If we do, the plugin won't work with Forrest 0.8 w/o manual copying of libraries. Therefore I'd suggest to move them back into the plugin-in dir at least until Forrest 0.9 is released. wdyt? Not clear what you mean. I am talking about two copies of "commons logging" ... http://svn.apache.org/viewvc/forrest/branches/UpdateFOPto094/lib/core/ -David David Crossley wrote: Ferdinand Soethe wrote: Thorsten Scherler wrote: Ferdinand Soethe wrote: - moved the libs from lib/core to the plugin-lib-dir IMO you moved too much (see the other mail). That's fixed. There are now copies of at least "commons-logging" jars. Yes I know. And both issues are related. fop requires the newer version of that lib and Forrest used the older version so I was not sure what happended if I removed it. I simply figured that two differently named versions of a library could coexist. How does library calling work inside. Does the caller know which version it needs an call the right library if there is more than one? Best regards, Ferdinand Soethe
Re: pdf-plugin with fop .94 - can sbdy please help?
Actually I regret having moved them back. If we do, the plugin won't work with Forrest 0.8 w/o manual copying of libraries. Therefore I'd suggest to move them back into the plugin-in dir at least until Forrest 0.9 is released. wdyt? Ferdinand David Crossley wrote: Ferdinand Soethe wrote: Thorsten Scherler wrote: Ferdinand Soethe wrote: - moved the libs from lib/core to the plugin-lib-dir IMO you moved too much (see the other mail). That's fixed. There are now copies of at least "commons-logging" jars.
Re: Decouple fo from skinconf (was Re: svn commit: r618400 )
If I understand you correctly I would have to add that pipeline to the plugins sitemap so that it looks for skinconf settings elsewhere and than what? Where and how would I have to store the settings formerly in skinconf? Best regards, Ferdinand Soethe
Re: How to merge FOP94-branch
David Crossley wrote: Ferdinand Soethe wrote: Thinking again: I'd also need to merge the pdf-plugin dir back into trunk so that change history of files is preserved. Can I do such a partial merge? Yes, see the svn book for instructions. Merge can operate at any level of the tree. However, why not just merge the whole lot. I'd like to do that but I have this tricky issue with Author: ferdinand Date: Mon Dec 10 23:53:07 2007 New Revision: 603165 URL: http://svn.apache.org/viewvc?rev=603165&view=rev Log: Replacing fop-0.20.5.jar with fop-0.94.jar, adding supporting modules and reconfiguring plugin to use it. Added: forrest/branches/UpdateFOPto094/lib/core/cocoon-fop-ng-impl-1.0.0-SNAPSHOT.jar (with props) forrest/branches/UpdateFOPto094/lib/core/commons-io-1.3.1.jar (with props) forrest/branches/UpdateFOPto094/lib/core/commons-io.LICENSE.txt forrest/branches/UpdateFOPto094/lib/core/commons-io.NOTICE.txt forrest/branches/UpdateFOPto094/lib/core/fop-0.94.LICENSE.txt forrest/branches/UpdateFOPto094/lib/core/fop-0.94.jar (with props) forrest/branches/UpdateFOPto094/lib/core/xmlgraphics-commons-1.2.jar (with props) forrest/branches/UpdateFOPto094/lib/core/xmlgraphics-commons.LICENSE.txt forrest/branches/UpdateFOPto094/lib/core/xmlgraphics-commons.NOTICE.txt Removed: forrest/branches/UpdateFOPto094/lib/core/fop-0.20.5.jar forrest/branches/UpdateFOPto094/lib/core/fop-0.20.5.jar.license.txt Modified: forrest/branches/UpdateFOPto094/plugins/org.apache.forrest.plugin.output.pdf/output.xmap where I removed fop-0.20.5.jar and added fop-0.94.jar in the same transaction and I didn't know how best to undo the deletion of fop-0.20.5.jar w/o undoing the rest. Best regards, Ferdinand Soethe
pdf-plugin with fop 94 is up and running
Thanks to Thorsten, the pdf-plugin with fop-94 is up and running. The remaining issues being - linkmap breaking trunk which is really a problem with illegal xml delivered to the pluginFOR-1067 - Thorstens suggestions to Decouple fo from skinconf (was Re: svn commit: r618400 ) which I'd like to leave for a next release of the plugin Any comments? Best regards, Ferdinand Soethe
Re: pdf-plugin with fop .94 - can sbdy please help?
Thorsten Scherler wrote: - moved the libs from lib/core to the plugin-lib-dir IMO you moved too much (see the other mail). That's fixed. - moved the style-sheets from common skin to plugin-resources-dir - adjusted output.xmap to the best of my understanding Try cocoon:// instead (see side note on the other mail) and I guess you get back the fo. Thanks Thorsten. That did the trick. - removed the fo-pipeline from main sitemap - changed build.xml What did you change? Did not see a commit. I actually had not committed build.xml yet. Done now. Best regards, Ferdinand Soethe
Re: svn commit: r618371 - in /forrest/branches/UpdateFOPto094: lib/core/ plugins/org.apache.forrest.plugin.output.pdf/lib/
Thorsten Scherler wrote: That should not include common libs: Thanks Thorsten. I had some doubts about these as well. But since I had added them I figured that pdf must be the only one using them atm. Will move them back in core. Best regards, Ferdinand Soethe
pdf-plugin with fop .94 - can sbdy please help?
I have prepared the pdf-plugin and done all the steps that I thought were needed: - moved the libs from lib/core to the plugin-lib-dir - moved the style-sheets from common skin to plugin-resources-dir - adjusted output.xmap to the best of my understanding - removed the fo-pipeline from main sitemap - changed build.xml - done a local-deploy - run fop94-forrest but something is badly wrong. I don't even get the .fo anymore. Any hints where I made a mistake? Thanks, Ferdinand
Re: How to merge FOP94-branch
Thinking again: I'd also need to merge the pdf-plugin dir back into trunk so that change history of files is preserved. Can I do such a partial merge? Best regards, Ferdinand Soethe Ferdinand Soethe wrote: If I manage to build everything into the plugin, I would like to apply those few remaining changes - delete main\webapp\skins\common\xslt\fo - remove fo-pipeline from sitemap directly to head and throw the branch away. Best regards, Ferdinand Soethe Johannes Schaefer wrote: What if Ferdinand manages to contain everything in the PDF/FOP-plugin? Thanks and Cheers! Johannes
Re: How to merge FOP94-branch
If I manage to build everything into the plugin, I would like to apply those few remaining changes - delete main\webapp\skins\common\xslt\fo - remove fo-pipeline from sitemap directly to head and throw the branch away. Best regards, Ferdinand Soethe Johannes Schaefer wrote: What if Ferdinand manages to contain everything in the PDF/FOP-plugin? Thanks and Cheers! Johannes
Re: linkmap breaks trunk
Johannes Schaefer wrote: How do I test plugins (in this case the sdocbook one) before committing? How about placing the uncommitted plugin code into your build/plugins directory then test? Best regards, Ferdinand Soethe
Re: linkmap breaks trunk
Thorsten Scherler wrote: On Sat, 2008-02-02 at 13:00 +0100, Ferdinand Soethe wrote: So what should I do if I have no time to clean up linkmap atm? Revert that fix so that trunk works again? I did this now, but please next time revert it straight away. salu2 Sorry about that. I was still trying to figure out if there was a way forward rather than unfixing that bug. But I haven't found one and nobody else either, so reverting it was probably the right choice. Thanks, Best regards, Ferdinand Soethe
[jira] Created: (FOR-1067) linkmap-to-document created illegal xml
linkmap-to-document created illegal xml --- Key: FOR-1067 URL: https://issues.apache.org/jira/browse/FOR-1067 Project: Forrest Issue Type: Bug Components: Core operations Affects Versions: 0.9-dev Reporter: Ferdinand Soethe linkmap-to-document creates invalid xml. to reproduce call linkmap.xmp and validate it. you will find following problems: 1. a used instead of link. however a is illegal for document 1.2 2. a-elements without (required) href-attribute. This would also be illegal if they where link-elements! 3. ul directly within ul (should have li inbetween) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: linkmap breaks trunk (was Re: [jira] Commented: (FOR-413) PDF: rendering fails when graphics too big - workaround inside)
Ferdinand Soethe wrote: So what should I do if I have no time to clean up linkmap atm? Revert that fix so that trunk works again? I looked some more into linkmap-to-document. Problem is that there are a number of illegal situations in this file such as a instead of link used a-elements without href (required) ul directly within ul (should habe li inbetween) I don't dare fixing all this because it might break the code later in the pipeline so for now I'll simply roll back my first change and make this an issue FOR-1067. Best regards, Ferdinand Soethe
linkmap breaks trunk (was Re: [jira] Commented: (FOR-413) PDF: rendering fails when graphics too big - workaround inside)
So what should I do if I have no time to clean up linkmap atm? Revert that fix so that trunk works again?
Re: [jira] Commented: (FOR-413) PDF: rendering fails when graphics too big - workaround inside
OK, a is now link and the document validates in principle. However with Johannes Testproject it still generates 6 error. Some of which are link without href (not legal) one is an ulo without content. I guess that stylesheet will need some further cleaning. Best regards, Ferdinand Soethe Thorsten Scherler wrote: On Fri, 2008-02-01 at 18:59 +0100, Ferdinand Soethe wrote: Thanks, Johannes, I already took the liberty to apply it: but did it make any difference in your tests. I just tested and the problem remains. linkmap.xml is still invalid. If you see http://svn.apache.org/viewvc?rev=614162&view=rev the fix is just to get back wholesite pdf working it is not addressing linkmap.xml. Linkmap.xml is declared as http://forrest.apache.org/dtd/document-v12.dtd";> and you are right that is not supported by v12. Why not updating lm:transform.linkmap.document to transform Best regards, Ferdinand Soethe
Re: [jira] Commented: (FOR-413) PDF: rendering fails when graphics too big - workaround inside
Thanks, Johannes, I already took the liberty to apply it: but did it make any difference in your tests. I just tested and the problem remains. linkmap.xml is still invalid. Best regards, Ferdinand Soethe
Re: How to merge FOP94-branch
David Crossley wrote: Ross are you talking about "using" Forrest plugins? IIUC, Ferdinand is talking about developing the code in svn trunk. As far as i can see there can only be one version. David is right. Is it at all possible to have two separate versions of a plugin in svn? And how would that work? Ferdinand i don't understand why we would want to maintain two separate versions. Good point. If the old plugin is still available for download and the new plugin is marked so that is works with 0.8 there is really no reason to still have the old code in svn. So what I'd do is: - publish the current state of the pdf-plugin if there are changes just checked: last change was April 10, 2007 thus before the 0.8-release thus no need to republish - update the version number of the plugin, move the libs and stylesheets and test this with fop94-branch - when working test the new plugin with forrest 0.8 and head - when working publish the plugin and remove fop-code in from head. wdyt? Ferdinand
Re: [jira] Commented: (FOR-413) PDF: rendering fails when graphics too big - workaround inside
David Crossley (JIRA) wrote: Both linkmap.pdf and wholesite.pdf work fine in current 0.9-dev trunk. Nevertheless Forrest generates invalid xml here and this should be adressed, shouldn't it? Don't forget that there was a fix recently in trunk for "wholesite". These issues should be discussed separately to this "graphics too big" issue. I'll try to find that on the list and see if that was after I created the branch. If so I'll fix that in the branch to. Best regards, Ferdinand Soethe
Re: How to merge FOP94-branch
If libs and stylesheets where moved to the plugin directory (where they belong) there could be two versions of the plugin 0.2 using old fop 0.3 using fop .94 As far as I can tell, these could then be used with Forrest 0.8 und higher and people had the option to use either fop-version with either Forrest version. Btw. How can we maintain two plugins of the same name but with different versions in the plugin directory? Thanks, Ferdinand David Crossley wrote: Ross Gardler wrote: Ferdinand Soethe wrote: We are almost there. The branch with FOP 94 is running smoothly and I'm planning to merge it back by the end of this week. Cool! Yes, congratulations. The branch changes Forrest core and the pdf-plugin Can I do a complete merge or will the plugin have to become a new version? I guess a new version is required or Forrest 0.8 runs into problems when using the modified plugin 0.2 that calls for libraries that it doesn't have. So here is what I'll do: - change version number of pdf-plugin in the branch to 0.3 - change required Forrest version number (but see below) Yes, both the plugin number and the Forrest required version number would be incremented. http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html#descriptor Please someone make sure that the existing plugin is deployed to our website (both locations) before changing it. - merge all changes You should merge changes from the whole trunk into branch first and then test. If all goes well you can merge back into trunk. This step is not required but sometimes it sometimes highlights a change in trunk that affects your changes in the branch. - create an instruction file for using the new fop in 0.8 by changing the plugin in properties to 0.3, adding the required libraries and replace the style sheets If there are manual install steps needed I don't think it's a good idea to claim that FOP is supported in 0.8 (hence change the minimal forrest version). We don't want support requests for this so it should be confident users only. This will mean the autodownload will not work for this plugin and the user will need to perform all steps manually including downloading the plugin manually. It would be better to do a 0.9 release. -David
[jira] Commented: (FOR-413) PDF: rendering fails when graphics too big - workaround inside
[ https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564104#action_12564104 ] Ferdinand Soethe commented on FOR-413: -- looking at linkmap.xml I see a document that claims to be DTD Documentation V1.2//EN but uses a-elements for linking which are not legal in this grammar. Probably - I didn't find my way all through the sitemap - this misrepresentation of the document type prevents it from being tranformed to proper document v1.3 which is expected when transforming to fop. Rather than hacking fop to support a elements I'd suggest to fix the linkmap-pileline to produce valid xml. > PDF: rendering fails when graphics too big - workaround inside > -- > > Key: FOR-413 > URL: https://issues.apache.org/jira/browse/FOR-413 > Project: Forrest > Issue Type: Bug > Components: Plugin: output.pdf >Affects Versions: 0.6 >Reporter: Olivier Jacques >Assignee: Ferdinand Soethe > Attachments: added-wide-PNG-to-howto.patch, FOP-Test.zip, murks.fo, > murks.fo, murks.zip, recovered-files.zip, remove-double-id.patch > > > When "forresting" a document that has embedded images, the PDF rendering > sometimes stops with this error message: > BROKEN: org.apache.fop.apps.FOPException: No meaningful layout in block after > many attempts. Infinite loop is assumed. Processing halted. > I've found that this is caused by images that are too big to fit in the PDF > page (took me some times :) ) > (Moved workaround from Description to Comment - see 2005-12-24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-413) PDF: rendering fails when graphics too big - workaround inside
[ https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563975#action_12563975 ] Ferdinand Soethe commented on FOR-413: -- The problem seems to be within linkmap since calling linkmap.pdf creates the same error. Calling linkmap.pdf with Forrest 0.8 I get a "The requested resource "/linkmap.pdf" could not be found"-error, so the problem doesn't see to be new. Will try to figure out why anyhow. > PDF: rendering fails when graphics too big - workaround inside > -- > > Key: FOR-413 > URL: https://issues.apache.org/jira/browse/FOR-413 > Project: Forrest > Issue Type: Bug > Components: Plugin: output.pdf >Affects Versions: 0.6 > Reporter: Olivier Jacques >Assignee: Ferdinand Soethe > Attachments: added-wide-PNG-to-howto.patch, FOP-Test.zip, murks.fo, > murks.fo, murks.zip, recovered-files.zip, remove-double-id.patch > > > When "forresting" a document that has embedded images, the PDF rendering > sometimes stops with this error message: > BROKEN: org.apache.fop.apps.FOPException: No meaningful layout in block after > many attempts. Infinite loop is assumed. Processing halted. > I've found that this is caused by images that are too big to fit in the PDF > page (took me some times :) ) > (Moved workaround from Description to Comment - see 2005-12-24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Plugins and dependend code
Working on the FOP-Update I started wondering, why stylesheets and libraries for the pdf-output-plugin are placed in core instead of the plugin directory. If it was placed in the plugin-dir one could easily change back between fop 0.2 and fop 0.94 by simple changing the line in forrest.properties. Is there a way to do this. Can a plugin have it's own libraries? wdyt? Ferdinand
How to merge FOP94-branch
We are almost there. The branch with FOP 94 is running smoothly and I'm planning to merge it back by the end of this week. Some questions for the experts remain: The branch changes Forrest core and the pdf-plugin Can I do a complete merge or will the plugin have to become a new version? I guess a new version is required or Forrest 0.8 runs into problems when using the modified plugin 0.2 that calls for libraries that it doesn't have. So here is what I'll do: - change version number of pdf-plugin in the branch to 0.3 - merge all changes - create an instruction file for using the new fop in 0.8 by changing the plugin in properties to 0.3, adding the required libraries and replace the style sheets Thanks for your comments, Ferdinand
Re: svn commit: r615253 - /forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl
I agree. Will check the sizing if headings and text in general before I change that. Best regards, Ferdinand Soethe Johannes Schaefer wrote: I would choose a smaller font size for sans headings they look too big now, IMHO. Johannes [EMAIL PROTECTED] schrieb: Author: ferdinand Date: Fri Jan 25 07:58:21 2008 New Revision: 615253 URL: http://svn.apache.org/viewvc?rev=615253&view=rev Log: Minor changes to typesetting of headings (font changed to sans-serif) and padding of box. Modified: forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl Modified: forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl URL: http://svn.apache.org/viewvc/forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl?rev=615253&r1=615252&r2=615253&view=diff == --- forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl (original) +++ forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl Fri Jan 25 07:58:21 2008 @@ -508,7 +508,7 @@ name="heading-type" select="//skinconfig/headings/@type" /> 3pt +name="padding-left">3pt 2pt +name="padding-top">4pt
Re: Plans for integrating FOP .94
Looks like it's almost done. fop 94 is integrated and stylesheets are adapted so that test documents look and work as well as before. Sometimes better as I smoothed some rough edges in the typesetting. FOR-413 is basically fixed and over-large images will not simply disappear but show clipped instead. As documented in the commit-msgs, scale-down-to-fit will not work in this version of fop. Promised for .95 and %-scaling of image height is buggy and not recommended. Have a look and let me know if you find anything that doesn't work. I'm planning to merge the branch back into trunk by the end of next week if nobody objects. Best regards, Ferdinand Soethe
Re: Windows-Installer for Forrest
After some playing around I created the attached script. You simply point it to the Forrest home dir (need text to say so) and it creates explorer context menu items to seed, run and compile a project. It still needs the license screen but that is not my point. What I'm trying to show is: - We wouldn't need to package all of Forrest in the installer. Enclosed script could be in Forrest root and Docs could instruct user to execute it once Forrest is unzipped. (I'd say if unzipping is beyond our user then this won't be the last problem they would have with Forrest) - With a small modification this installer could be generic and would not require a change with every release. - In addition we could create a second installer that lives and is executed by "Forrest seed" and creates Start-Menu items for runinng and compiling the seeded project. With that we could actually do away with the context menu items run and comile and just keep seed. wdyt? Best regards, Ferdinand Soethe ; install-apache-forrest-0.8-in-explorer-context-menu.nsi ; ; Installation script to create context menu items ; for windows explorer that seed, run and compile ; a forrest in a given explorer folder ; The name of the installer Name "Apache Forrest 0.8 Context Extensions" ; The file to write OutFile "install-apache-forrest-0.8-in-explorer-context-menu.exe" ; The default installation directory InstallDir "$PROGRAMFILES\apache-forrest-0.8\" ; Short Name for Context menu VAR ShortName ; ; Pages ; Page components Page directory Page instfiles ; Section "Explorer Context Menu Extensions" strcpy $ShortName "Forrest 0.8" WriteRegStr HKCR "FOLDER\shell\$ShortName run" '' "$ShortName run" WriteRegStr HKCR "FOLDER\shell\$ShortName run\command" '' "cmd.exe /k cd %L&& $INSTDIR\bin\forrest.bat run" WriteRegStr HKCR "FOLDER\shell\$ShortName compile" '' "$ShortName compile" WriteRegStr HKCR "FOLDER\shell\$ShortName compile\command" '' "cmd.exe /k cd %L&& $INSTDIR\bin\forrest.bat" WriteRegStr HKCR "FOLDER\shell\$ShortName seed" '' "$ShortName seed" WriteRegStr HKCR "FOLDER\shell\$ShortName seed\command" '' "cmd.exe /k cd %L&& $INSTDIR\bin\forrest.bat seed" SectionEnd
Re: Windows-Installer for Forrest
Great. I think this is a great idea and long overdue. Where can I look up the documentation for the nsi-language? > - Copies forrest 0.8 to the program directory (C:\Program > Files) As far as I gather that name of the program-directory is language specific and becomes C:\pogramme in german Windows? > The installation is based on the zip-file for forrest-0.8 > and results in a total size of 23.088.307 Bytes (slightly > *smaller* > than the original zip file). Does it have to become a compiled exe or could it simply work with the Forrest zip? Some first comments: - I'd rather not set FORREST_HOME as a permanent environment variable but rather set it in the batch-file that starts forrest. That also makes it possible to have separate versions of forrest installed. - To simplify working with projects I can contribute a solution that created a context menu item for directories in the windows explorer. That way you simply right-click any project directory and select menu items such as "forrest 0.8 run", "forrest 0.8 compile" etc. Best regards, Ferdinand Soethe
Re: Plans for integrating FOP .94
[EMAIL PROTECTED] wrote: > Author: ferdinand > Revision: 603165 > Modified property: svn:log > > Modified: svn:log at Fri Dec 28 17:50:48 2007 > -- > --- svn:log (original) > +++ svn:log Fri Dec 28 17:50:48 2007 > @@ -1 +1,2 @@ > Replacing fop-0.20.5.jar with fop-0.94.jar, adding supporting modules and reconfiguring plugin to use it. > +Block source is adapted from fop-0.20.5-block and compiled with Coccoon r351990 (like all other blocks). Complete sources are included in jar. Have now changed the svn-log to clarify the bases of that change. As mentioned before the jars is complete with all required sources which are the same Cocoon revision as our other blocks. The source for this block being adapted from the old fop-0.20.5-block. However, since there already is a adapted fop-0.94-block in the current cocoon trunk, this block here should remain a temporary hack until Forrests is updated to the current cocoon release. Best regards, Ferdinand Soethe
Re: Plans for integrating FOP .94
David Crossley wrote: > Would you please be more explicit in your svn commit > message for this block jar. In the past we have always > mentioned the revision number from which it was built. > The commit log can be edited: > svn propedit svn:log --revprop -r603892 ... As far as I understand the block was build from the sources that were used to build all our cocoon blocks and FOP 0.94. The code of the block itself, I understand, was adapted for FOP 0.94. The source is included in the jar. Should I simply say so in the message? > Also we need to know what are the source changes. Sources of the block are included. How best to document changes of source code we don't maintain? > Perhaps link to a Jira issue. Updating to FOP 0.94 is not an issue yet. Should I create one? Best regards, Ferdinand Soethe
Re: Plans for integrating FOP .94
David Crossley wrote: > Earlier in this thread i referred you to issue > https://issues.apache.org/jira/browse/FOR-1017 > which links to notes about that "externals" problem > - lots of effort was previously spent to solve it. > https://issues.apache.org/jira/browse/FOR-1015 Sorry, David, I did not follow up on that because I thought it was a discussion about upgrading our Cocoon. Which I didn't want to do because the new pdf was also supposed to be used as a patch for the released 0.8. I have now added the info from that discussion as a text file to the cocoon directory. > New Revision: 604147 > > URL: http://svn.apache.org/viewvc?rev=604147&view=rev > Log: > Added info on how to retrieve sources > > Added: > forrest/trunk/etc/cocoon_upgrade/GettingCocoonSources.txt Best regards, Ferdinand Soethe
Re: Plans for integrating FOP .94
Johannes Schaefer wrote: > Yes, the layout became messed up but this may (hopefully!) be fixed > on XSL level. I think this will be possible. Will take care of that the next few weeks. > >> Btw: The update did not fix FOR-413. Things got worse. Next > > I'm not so pessimistic ... at least I do not get any "infinite loop" > errors any more---which is a big improvement! > > I just tried out the test project and all pages seem to work! Hmmm. After a restart I'm now getting the images that were broken before (even though they seem to be a page too far). But I'm not getting an image in GIF-Image (OK), are you? > The images that are too high are cut off at the end and no scaling is > applied as before, even not to wide images. Yes, I can see them being cut off. Which is probably going to remain that way since we cannot determine the rendered size of the image in the style sheet. So a mode like switch to scaling when image is too big would have to be done by FOP, right? Best regards, Ferdinand Soethe
Re: Plans for integrating FOP .94
Thanks to Jeremias, we have now completed the update to FOP .94. To do so he has recompiled the block with the cocoon revision that Forrest currently uses. Which by the way turned out to be rather difficult because there where externals used in cocoon that could not be identified by the revision number we logged when taking that snapshot. So the block is a hack, but it works as far as I can tell. So, the new FOP is integrated and used (in that branch) the transformation is updated to complete processing without fatal errors, from now on it's all about adjusting the transformation to create at least as good a pdf as it did before. Btw: The update did not fix FOR-413. Things got worse. Next step is to check the transformation and make it standard conforming. Best regards, Ferdinand Soethe
Re: Plans for integrating FOP .94
Thorsten Scherler wrote: Thanks Thorsten. That helped quite a bit. > Did you try to "just" add commons logging as well (drop the lib)? I'd try if I knew where to find that lib :-) > ..or (better) update our cocoon version to the current cocoon one or > switch to cocoon-2.1.x. Otherwise we are really starting to fork cocoon. That makes sense in context of what you write below. So should I do that? And how do I get started. I installed maven and checked out Cocoon trunk last night. But building repeatedly failed with the message > Failed tests: > > testRefreshSyncURI(org.apache.cocoon.components.source.impl.CachingSourceTestCase) Is there a better way? Can I build the needed blocks individually? Should I try another version? Thanks, Ferdinand > >> Now could somebody perhaps explain to me in simple terms how >> to best accomplish that (recompile that block)? > > I think that is not that easy, since they did not only switch the > container but as well they building engine (now maven). > > Basically you need to get our cocoon revision and then manually patch > the FOP block from our revision to current HEAD of the block. You need > to analyze every single change and decide whether or not it is container > related, since you do not want any changes that are using Spring > features. > > That leaves you with a forked FOP block that should be build with ant > instead of maven. Then you need to find the old documentation how to > build a block (I reckon looking at the 2.1.x docu may do). > > The task is not that trivial and leaves us with a fork. > > HTH a wee bit. > > salu2 > >> Thanks, >> Ferdinand >>
Re: Plans for integrating FOP .94
David Crossley wrote: > I presume that you will need to operate with our old > version of Cocoon-2.2 and rework the Cocoon FOP Block. Actually, Jeremias (who is helping me with this) suggested to try and compile a new FOP Block from current coccoon trunk. But having integrated that (http://svn.apache.org/viewvc?rev=603165&view=rev) I'm running into a logging problem with Forrest where the browser tells me > HTTP ERROR: 500 > org%2Eapache%2Ecocoon%2Eblocks%2Efop%2EFOPNGSerializer%2EgetLogger%28%29Lorg%2Fapache%2Fcommons%2Flogging%2FLog%3B and Jetty says > 08:01:19.609 WARN!! Error for /fop-update/xdoc-gif-ok.pdf >> java.lang.NoSuchMethodError: >> org.apache.cocoon.blocks.fop.FOPNGSerializer.getLogger()Lorg/apache/commons/logging/Log; >> at >> org.apache.cocoon.blocks.fop.FOPNGSerializer.resolve(FOPNGSerializer.java:230) >> at org.apache.fop.apps.FOURIResolver.resolve(FOURIResolver.java:129) >> at org.apache.fop.apps.FopFactory.resolveURI(FopFactory.java:729) >> at org.apache.fop.apps.FOUserAgent.resolveURI(FOUserAgent.java:385) >> at org.apache.fop.apps.FOUserAgent.resolveURI(FOUserAgent.java:358) >> at org.apache.fop.image.ImageFactory.loadImage(ImageFactory.java:190) >> at org.apache.fop.image.ImageLoader.loadImage(ImageLoader.java:56) >> at >> org.apache.fop.image.ContextImageCache.getImage(ImageFactory.java:432) >> at org.apache.fop.image.ImageFactory.getImage(ImageFactory.java:157) >> at >> org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:70) >> at org.apache.fop.fo.FObj.processNode(FObj.java:125) >> at >> org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320) >> at >> org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) >> at >> org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) >> at >> org.apache.cocoon.environment.internal.EnvironmentChanger.startElement(EnvironmentStack.java:140) >> at >> org.apache.xml.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:204) >> at >> org.apache.xml.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:277) >> at >> org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:243) >> at >> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1399) >> at >> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) >> at >> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374) >> at >> org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393) >> at >> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176) >> at >> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) >> at >> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374) >> at >> org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393) >> at >> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176) >> at >> org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393) >> at >> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176) >> at >> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) >> at >> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374) >> at >> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) >> at >> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374) >> at >> org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393) >> at >> org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176) >> at >> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) >> at >> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374) >> at >> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) >> at >> org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374) >> at >> org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) >> at >> org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281) >> at >> org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367) >> at >> org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3458) >>
Re: Unreleased Coccon Code in Forrest 0.8
I asked Jeremias Maerki to point out where we can look up this rule. Best regards, Ferdinand Soethe
[jira] Assigned: (FOR-413) PDF: rendering fails when graphics too big - workaround inside
[ https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ferdinand Soethe reassigned FOR-413: Assignee: Ferdinand Soethe (was: Johannes Schaefer) I'm plannung to fix this problem by updating FOP to the current release and adjusting FOP-stylesheets until Feb 2008 > PDF: rendering fails when graphics too big - workaround inside > -- > > Key: FOR-413 > URL: https://issues.apache.org/jira/browse/FOR-413 > Project: Forrest > Issue Type: Bug > Components: Plugin: output.pdf >Affects Versions: 0.6 >Reporter: Olivier Jacques >Assignee: Ferdinand Soethe > Attachments: FOP-Test.zip, murks.fo, murks.fo, murks.zip, > recovered-files.zip > > > When "forresting" a document that has embedded images, the PDF rendering > sometimes stops with this error message: > BROKEN: org.apache.fop.apps.FOPException: No meaningful layout in block after > many attempts. Infinite loop is assumed. Processing halted. > I've found that this is caused by images that are too big to fit in the PDF > page (took me some times :) ) > (Moved workaround from Description to Comment - see 2005-12-24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Plans for integrating FOP .94
David Crossley wrote: > I presume that you will need to operate with our old > version of Cocoon-2.2 and rework the Cocoon FOP Block. I'm not sure what needs to be done yet but I'll let you now as soon as I have done my homework :-) Ferdinand
Re: Plans for integrating FOP .94
I guess you are right. So first step would be to create a branch by issueing the following command: svn copy https://svn.apache.org/repos/asf/forrest/trunk \ https://svn.apache.org/repos/asf/forrest/branches/UpdateFOPto094\ -m "Updating fop to .94 and adjust fo-stylesheets" then checkout this new branch an work on it. Would be nice if anybody could check and confirm this before I mess up something by accident. Thanks, Ferdinand Ross Gardler wrote: > Ferdinand Soethe wrote: >> I'm planning to integrate the latest released version of fop >> (.94) into trunk to solve FOR-413 and improve pdf-generation >> in general. (A patch for .8 will also be provided later on.) >> >> Since fop .94 is much closer to the standard, I will also >> have to modifiy the transformation to xsl-fo in the >> pdf-output-plugin. >> >> Since switching to fop .94 will probably break >> pdf-generation, I'm planning on working on this in my local >> copy until I have roughly restored previous functionality >> (rather than creating a branch). >> >> Any comments, suggestions? > > All work should be done in a branch. People can then see what you are up > to and provide assistance, point out potential problems etc. > > It's much easier for us to review the work if it is done piece by piece. > besides other people need better PDF generation (myself included). If > time allows those people will be able to help (although to be honest, > I'm unlikely to help given my time schedule at present). > > Ross
Plans for integrating FOP .94
I'm planning to integrate the latest released version of fop (.94) into trunk to solve FOR-413 and improve pdf-generation in general. (A patch for .8 will also be provided later on.) Since fop .94 is much closer to the standard, I will also have to modifiy the transformation to xsl-fo in the pdf-output-plugin. Since switching to fop .94 will probably break pdf-generation, I'm planning on working on this in my local copy until I have roughly restored previous functionality (rather than creating a branch). Any comments, suggestions? Kind regards, Ferdinand
Re: Unreleased Coccon Code in Forrest 0.8
Ignore these last two paras. Thunderbird seems to have highjacked some lines from another draft message. Arg!! Ferdinand Soethe wrote: > Feel free to send my that proposal if you want my comments. > Curious to see what you are up to. > >> Which train do I take? I hate airplanes. > > You could come by bus. Plenty of companies now fly Airbus :-) > > > Take care, > Ferdinand
Unreleased Coccon Code in Forrest 0.8
An Apache colleague looking at Forrest 0.8 just noticed that we have used unreleased Cocoon Code in our release and told me that this is not longer permitted. Do we need top change our release procedures to avoid that in the future? Feel free to send my that proposal if you want my comments. Curious to see what you are up to. > Which train do I take? I hate airplanes. You could come by bus. Plenty of companies now fly Airbus :-) Take care, Ferdinand
[jira] Updated: (FOR-1001) Broken seed site: Loss of menu/tab context on Samples-tab
[ https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ferdinand Soethe updated FOR-1001: -- Attachment: error2.png Screenshot of remaining problem with subtab. > Broken seed site: Loss of menu/tab context on Samples-tab > - > > Key: FOR-1001 > URL: https://issues.apache.org/jira/browse/FOR-1001 > Project: Forrest > Issue Type: Bug > Components: Other >Affects Versions: 0.9-dev > Reporter: Ferdinand Soethe > Attachments: error.png, error2.png > > > On a freshly seeded site, accessing the samples tab will lead to a complete > loss of context in the menu and tab system that is neither the current tab > nor the current menui tem are emphasized. This problem is usually due to > errors in the site.xml or tab.xml-files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1001) Broken seed site: Loss of menu/tab context on Samples-tab
[ https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498151 ] Ferdinand Soethe commented on FOR-1001: --- Thanks for your help. I did a complete fresh check-out of head and I'm now getting the same result as Forrest zones (See Screenshot error2.png) So main tab and menu highlights work o.k., sub tab highlight still doesn't work properly. > Broken seed site: Loss of menu/tab context on Samples-tab > - > > Key: FOR-1001 > URL: https://issues.apache.org/jira/browse/FOR-1001 > Project: Forrest > Issue Type: Bug > Components: Other >Affects Versions: 0.9-dev >Reporter: Ferdinand Soethe > Attachments: error.png, error2.png > > > On a freshly seeded site, accessing the samples tab will lead to a complete > loss of context in the menu and tab system that is neither the current tab > nor the current menui tem are emphasized. This problem is usually due to > errors in the site.xml or tab.xml-files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1001) Broken seed site: Loss of menu/tab context on Samples-tab
[ https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497973 ] Ferdinand Soethe commented on FOR-1001: --- Check out the screenshot: When a site works ok. the current tab is shown in blue and the current menu item is open, visible and emphasized. When you look at the screenshot the Home tab is blue (wrong), both subtabs are blue (wrong and impossible) and the menu shows the typical signs of a broken system (all menus visible, none open). Mind you none of this will make Forrest site or run fail. The system simply doesn't work the way it is supposed to work. Look for my previous postings on site.xml and tab.xml if you want more of an explanation. Best regards, Ferdinand Soethe > Broken seed site: Loss of menu/tab context on Samples-tab > - > > Key: FOR-1001 > URL: https://issues.apache.org/jira/browse/FOR-1001 > Project: Forrest > Issue Type: Bug > Components: Other >Affects Versions: 0.9-dev > Reporter: Ferdinand Soethe > Attachments: error.png > > > On a freshly seeded site, accessing the samples tab will lead to a complete > loss of context in the menu and tab system that is neither the current tab > nor the current menui tem are emphasized. This problem is usually due to > errors in the site.xml or tab.xml-files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FOR-1001) Broken seed site: Loss of menu/tab context on Samples-tab
[ https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ferdinand Soethe updated FOR-1001: -- Attachment: error.png Screenshot > Broken seed site: Loss of menu/tab context on Samples-tab > - > > Key: FOR-1001 > URL: https://issues.apache.org/jira/browse/FOR-1001 > Project: Forrest > Issue Type: Bug > Components: Other >Affects Versions: 0.9-dev > Reporter: Ferdinand Soethe > Attachments: error.png > > > On a freshly seeded site, accessing the samples tab will lead to a complete > loss of context in the menu and tab system that is neither the current tab > nor the current menui tem are emphasized. This problem is usually due to > errors in the site.xml or tab.xml-files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FOR-1001) Broken seed site: Loss of menu/tab context on Samples-tab
Broken seed site: Loss of menu/tab context on Samples-tab - Key: FOR-1001 URL: https://issues.apache.org/jira/browse/FOR-1001 Project: Forrest Issue Type: Bug Components: Other Affects Versions: 0.9-dev Reporter: Ferdinand Soethe On a freshly seeded site, accessing the samples tab will lead to a complete loss of context in the menu and tab system that is neither the current tab nor the current menui tem are emphasized. This problem is usually due to errors in the site.xml or tab.xml-files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Proposal] forrest clean removing build/
Thorsten Scherler wrote: > See "Re: svn commit: r536953 [1/14]" why I would like to change the > behavior. Sounds like a bug. Makes sense to fix it. Not sure about side-effects of removing build completely, so +0 Ferdinand
What is behind this?
I'm using a project sitemap with an entry
>
>
>
> src="{project:content.xdocs}{1}{2}.html" />
>
> src="{project:resources.stylesheets}/html2body.xsl" />
> src="cocoon:/{1}linkmap-{2}.html"/>
> src="{forrest:stylesheets}/declare-broken-site-links.xsl" />
>
>
>
>
that creates a direct path for html-documents.
But when I process the documents I get this message from linkrewriter.
After some fiddling everything works fine in dynamic mode but it doesn't
in static mode. Any ideas?
Best regards,
Ferdinand Soethe
Re: [Proposal] forrest clean removing build/
Thorsten Scherler wrote: > I would like to propose that "forrest clean" removes the whole build/ > directory instead only some directories within. > > I no concerns are issued within the next 72 hours I will change the > corresponding ant target to remove the whole build/. What's your reason for that proposal? I had a similar issue some time ago because to many ../ in a link would create content below the site-dir but that would require some other fix to make sense. Best regards, Ferdinand Soethe
Why not use regexp-matcher for *.html-pipelines
Looking at Cyriaques elegant solution for php-processing and finding a similar one used for matching fo's in sitemap > I wonder why we are not using as similar matcher to get rid of that redundant code in sitemap > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there a reason it is not used? Thanks, Ferdinand
Re: fixing bugs in trunk or branch
I'm sorry to have stepped out of line. I hadn't found Cyriaques solution when I looked for it. So I tracked down the bug on my own (in far too much time) and wanted to share the work with others. That's all. What I don't get: Had I found Cyriaques solution and copied it in .7 what would have been different? It still would have required testing give that .7 is a different environment that .8. It still would have only been me to test it given. We still wouldn't be sure that it really works. And I may be mistaken here but I thought the version I fixed is a yet unreleased update to a released version. Not? Best regards, Ferdinand P.S. One thing I really really disliked about commercial software was the fact that you were always forced into upgrading because bugs would only get fixed in new releases.
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Thanks for that pointer David. Cyriaque actually fixed the same bug in a different way. So no need to apply this to other versions. > This seems like a strange place to be handling processing > instructions and xml comments. The FOR-555 indicate that > there is a wider issue. Did look at FOR-555 and my understanding was that it was meant to remove namespaces that had wormed their way into the final output. Handling PIs and probably comments separatelly is necessary because of the way they are treated differently in xsl and can't be 'unnamespaced' the way it was done for elements and attributes. Best regards, Ferdinand
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Thorsten Scherler wrote: > I did not know that the 0.7 branch is the version where we do such > bugfixes. > Please, do bugfixes in trunk and not in such old branches such as 0.7. > You are the only person that I know that is fixing stuff in an already > released and antique version. I corrected this bug in the current version of .7 because I have a project that is still using .7 and needed this fix. In addition I offered to apply this fix to .8 and trunk. Not sure what is wrong about that. > It is much more important to fix stuff in trunk! Perhaps that depends on the point of view. My clients using a production version of Forrest would certainly like to see bugs fixed in the current version. Best regards, Ferdinand Soethe
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
If nobody has any objections I'd apply this fix to .8 and head as well next week. Best regards, Ferdinand Soethe [EMAIL PROTECTED] wrote: > Author: ferdinand > Date: Sun May 6 03:24:22 2007 > New Revision: 535593 > > URL: http://svn.apache.org/viewvc?view=rev&rev=535593 > Log: > Attempt to fix disappearance of processing-instructions. > > Modified: > > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > > Modified: > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > URL: > http://svn.apache.org/viewvc/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl?view=diff&rev=535593&r1=535592&r2=535593 > == > --- > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > (original) > +++ > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > Sun May 6 03:24:22 2007 > @@ -20,9 +20,14 @@ > > > > - select="@*|*|text()|processing-instruction()|comment()"/> > + > > > + > + > + > + > + > > > > > > >
Re: Problems activating sitemap-debugging in .7
Thanks David, that was a good lesson in how to track things down. Nevertheless, adding the previous change into .7 did not change anything. Any other ideas? Best regards, Ferdinand Soethe
Problems activating sitemap-debugging in .7
I need to debug some site maps in a .7 installation so I tried to activate the SimpleSitemapExecutor for .7 like David did for .8. - Looked for and found the class in cocoon-profiler-block-2.2.0-dev-r125082.jar in lib/core - added to forrest-core.xconf - checked that I have an entry for debug in logkit. However when I run Forrest I get this message in error.log. org.apache.avalon.framework.configuration.ConfigurationException: Cannot find class org.apache.cocoon.profiler.debugging.SimpleSitemapExecutor for component at file:/C:/forrest/0.7x/main/webapp/WEB-INF/xconf/forrest-core.xconf:730:25 What else is required to use/find/load this component? Or is there something else wrong? Ferdinand
Re: [Brainstorming] 0.9 release
David Crossley wrote: > First step is to review the issues that are scheduled > for 0.9-dev version. Many of these were just pushed over > in an effort to get the 0.8 release out. Now we need to > review the Roadmap and get realistic. Whatever happended with the move to xhtml. I didn't see it anywhere in the issues scheduled for .9. I'd really like to get this done before any more work goes into the old core format. Best regards, Ferdinand Soethe
Re: [Vote] please vote for the release using RC2
Just did a bit of research in the locale issue with seed side: Turning off project.i18n (to false) in forrest.properties would fix the issue in both static and dynamic versions of the seed side. Any chance to change that in the release or is that a nono without doing an RC3? Regards, Ferdinand
Re: [Vote] please vote for the release using RC2
Ross Gardler wrote: > I think it is significant, but I think it will affect so few users it > should not stop this release. In particular I wonder why no other tester > found the same problem and whether this is an indicator of how many > users will hit it. Perhaps this has to do with the fact that most test use english locale systems? How can we know that it won't hit many users until we understand the problem? David Crossley wrote: > This is the way that the i18n internationalisation > works now. For me with English as my default locale > it generates in build/site/en/ > Regarding the content, i expect if you provided > German source (e.g. index.de.xml) then it should work. I my opinion our seed system should look and work right in any locale. And to me it seems like it doesn't. Poor first impression, kind of like a demo system that crashes when you try it, don't you think? Regards Ferdinand
Re: [Vote] please vote for the release using RC2
0 I don't think the problem with the seed site is minor. Do you? Ferdinand Ross Gardler wrote: > (Yes, there are a few minor problems, but the average user experience > will be fine)
Re: [Vote] please vote for the release using RC2
Finally found some time to download an test RC2.
What I found:
Install
Only minor documentation stuff:
./index.html
- I'd really like it to mention that you should be online when you first
run forrest after install so that the plugins can be downloaded.
Site-Author
Runs and compiles well.
Only minor content issues:
./index.html
- The text in the box is misleading: "16 April 2007 Forrest-0.8
released: Features the Locationmap. (More)" suggests that you learn
more about locationmaps but takes you to the download.
- we still have a loss of context opening this document (the menu
collabses and doesn't show which part of the site it open) through the
download-menu item.
Sample Site
Here is a more serious issue:
Using Java 1.5 and a german Windows XP Pro Forrest will generate the
seed site ok and w/o error. But the site is empty and content is in
site/de/... and when I open index html I get the menu headings and tabs
in German ("Über" instead of "About") while menu items and texts are in
English.
Same when I Forrest run the new project.
Regards,
Ferdinand
Re: [headsup] recent change in broken link handling
For my projects the broken-links-file has often been important in identifying the problem. I'd be sad to see it become useless. Ferdinand
Re: [Proposal] Release Plan for Forrest 0.80
+1 will be online this week and try to put in some time for testing. Regards, Ferdinand Soethe
[jira] Created: (FOR-976) PlugIn to identify all references to a given page or resource
PlugIn to identify all references to a given page or resource - Key: FOR-976 URL: https://issues.apache.org/jira/browse/FOR-976 Project: Forrest Issue Type: New Feature Components: Plugins: Potential new Reporter: Ferdinand Soethe It currently requires intimate knowledge of Forrest to find out if a given resource is still referred to by other parts of a project. Using grep searches requires a look up of all alternative names of such a resource (such as its name in the site:-protocol etc.). This plugin could at least deliver all possible names that one needs to look for. Even better seems an xml-file of references created by the plugin during a 'forrest site' that could then be used to provide a comprehensive list. Best would be a dynamic lookup that also works in dynamic mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r523017 - /forrest/trunk/site-author/content/xdocs/docs_0_80/howto/howto-custom-html-source.xml
David Crossley wrote: > and to add a Requirement to read our "Sitemap Reference". Ah, good one. Thanks. > Does this re-working now mean that we can remove the old linked > docs? ... > docs_0_80/howto/forrest.xmap.html > docs_0_80/howto/project_sitemap.xmap.html > docs_0_80/howto/sitemap.xmap.html As far as this doc is concerned yes. But since I didn't know who else uses it, I haven't done it. (I really miss a function in Forrest that give you all the links to a given document). Regards, Ferdinand Soethe
