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
change?
Regards,
Ferdinand Soethe
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
I have some trouble using xi:include with head.
When I last used it it 0.7 something like
xi:include href=indextest.xml
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
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
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/
^
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
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
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
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
those
pdf-specific settings into the plugin-properties.
Best regards,
Ferdinand Soethe
believed the solution was so close.
Best regards,
Ferdinand Soethe
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
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 credits):
credit role=pdf
nameBuilt
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
regards,
Ferdinand Soethe
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
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
for 0.9?
Or would somebody wanting to use the new plugin with 0.8
also have to patch the property name=forrest.version
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
.
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
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
.
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
,
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
] [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
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
.
Any ideas how to fix that?
Best regards,
Ferdinand Soethe
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
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
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
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:
, I will fix that.
Best regards,
Ferdinand Soethe
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
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
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
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
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
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
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
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
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
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
like to leave for a next release of the plugin
Any comments?
Best regards,
Ferdinand Soethe
(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
So what should I do if I have no time to clean up linkmap
atm? Revert that fix so that trunk works again?
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
: 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
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
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
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
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
-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
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
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
[
https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563975#action_12563975
]
Ferdinand Soethe commented on FOR-413:
--
The problem seems to be within linkmap since
[
https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564104#action_12564104
]
Ferdinand Soethe commented on FOR-413:
--
looking at linkmap.xml I see a document
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
by the end
of next week if nobody objects.
Best regards,
Ferdinand Soethe
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
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
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
switch
to scaling when image is too big would have to be done by
FOP, right?
Best regards,
Ferdinand Soethe
I asked Jeremias Maerki to point out where we can look up
this rule.
Best regards,
Ferdinand Soethe
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
[
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
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
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
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.
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
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
[
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
[
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
[
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
: 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
[
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
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
but it doesn't
in static mode. Any ideas?
Best regards,
Ferdinand Soethe
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
Looking at Cyriaques elegant solution for php-processing and finding a
similar one used for matching fo's in sitemap
map:match type=regexp pattern=^(.*?)([^/]*).fo$
I wonder why we are not using as similar matcher to get rid of that
redundant code in sitemap
!--pipeline that marries the docs
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
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
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=revrev=535593
Log:
Attempt to fix
clients using a production
version of Forrest would certainly like to see bugs fixed in the current
version.
Best regards,
Ferdinand Soethe
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
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
component role=org.apache.cocoon.sitemap.SitemapExecutor
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
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.
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)
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
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
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
+1
will be online this week and try to put in some time for testing.
Regards,
Ferdinand Soethe
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
I'd appreciate sbdy checking this for accuracy since I had to change
quite a bit in this document.
Regards,
Ferdinand Soethe
[EMAIL PROTECTED] wrote:
Author: ferdinand
Date: Tue Mar 27 10:49:34 2007
New Revision: 523017
URL: http://svn.apache.org/viewvc?view=revrev=523017
Log:
FOR-922
? Or is that number a left-over
from pre subversion times?
Btw:
That method of converting the sitemap to an html-file in hindsight seems
really a bit waste of time.
So instead I'm planning on putting commented markers into the sitemap
and refer to those in the document.
Regards,
Ferdinand Soethe
I just noticed that there are quite a few changes in forrest.xmap that
require changes to
How to customize processing of html source
Is it correct to say that (forrest.xmap line 216)
map:match type=wildcard pattern=**.xml
map:select type=exists
map:when
don't get is why we no longer have that idgen-step
map:transform type=idgen /
which was there in 0.7 and is still used in .8 for ihtml.
Any explanations?
Regards,
Ferdinand Soethe
Just found the idgen-step where it has always been (in the
body-*.html-matcher). Pardon my confusion. Problem solved.
Ferdinand
Thanks for the pointer David.
I fixed and committed that.
So how about generating a new 0.7-release some time soon?
I really don't like the idea that the first thing people try - generate
docs - will fail in the released version.
wdyt
David Crossley wrote:
See FAQ:
Ross Gardler wrote:
Now let me think about what we need to do to make this work. More to
follow...
Yes please. Making it work that way would be a lot better than a new 0.7
release ...
Thanks
Ferdinand
I'm just preparing new instructions for getting started with Forrest 0.7
for a presentation and I'm running into a strange kind of problem:
Here is what I did
- Download Forrest 0.7
- Set Environment and Path for Windows XP
- cd to site-author
- execute forrest run
- try localhost: in my
1 - 100 of 470 matches
Mail list logo
