|
document2fo.xsl is currently very inflexible with regard to including images in the PDF. If we can use a cocoon pipeline here, that would be great. If not, we might want to consider a single directory for content, and differentiate the files using site.xml (this approach was discussed earlier, but I don't remember the advantages/disadvantages right now). This would let the XSL find the images in most if not all cases.
Other (future) output formats may have similar problems inlining images. fyi, here's how it works now. Relative references to images will break if the image is in the raw directory because the relative reference is only correct in the build/site/ dir not in the src/ dir which we need. <xsl:variable name="imgpath"> <xsl:choose> <!-- resources image dir --> <xsl:when test="starts-with(string(@src),'images/')"> <xsl:value-of select="concat($imagesdir,substring-after(@src,'images'))"/> </xsl:when> <!-- already absolute --> <xsl:when test="contains(string(@src),':') or starts-with(string(@src),'/')"> <xsl:value-of select="@src"/> </xsl:when> <!-- relative to document --> <xsl:otherwise><xsl:value-of select="concat($xmlbasedir,@src)"/></xsl:otherwise> </xsl:choose> </xsl:variable> Stephan E. Schlierf wrote:
... > So the problem is that I placed my png-files in > src/domentation/content/xdocs/images/ > and fop expects them in > src/documentation/resources/images/ > At least, after moving them to src/documentation/resources/images/ they are > correctly displayed in a pdf-file. > > I was a little bit confused: I thought I should place my images in that > directory where the images are located after a "forrest seed". Remember to review the docs.
In particular this paragraph is deprecated: http://forrest.apache.org/docs/your-project.html#images Forrest behaves as explained on that document. So we need to remove the code at the same time, for both fo and html documents.
The code has not been removed for compatibility reasons. I agree that we must remove the code, and have Forrest help the user in moving files to the new location.
This task will be much easier to complete once we have moved to Locationmap on all internals.
Moving out of 0.8 roadmap as that is the release that will include the LM stuff. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Redefine project documentation dirs
that Forrest will have in version 0.7 .
"Cleaning Forrest source directory madness"
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=forrest-dev@xml.apache.org&msgNo=5715
Below is a summary of the results that have come from this thread:
Conceptually:
documentation
content -> model
- files to process (1)
- files not to process (2)
resources -> controller
skins -> view
We would have use definable (KISS)
files to process-dir (1)
files not to process-dir (2)
What can [files to process (1)] contain?
- *.xml (documentdtd, faq, changes, todo, status, etc)
- *.html (html4, to be tidied)
- *.xhtml (xhtml1, xhtml2-dev)
- *.wiki
- *.png,gif,etc
The default content dirs 1,2 would be:
documentation/
content/*.xml (1)
content/images/*.png (1)
content/raw/foo.html (2)
The only special dir that will remain is "raw", and it seems that there
is a real-life use case for it.
Mind me, we still add a **.* matcher at the end of the
content-handling pipeline, so that content/** can still contain anything
(ie cocoon can proces it but in this case can also decide to just pass
along).
But as you know in this way I cannot easily cater for the special case
in which I want to explicitly have something as-is, like for example a
raw document-dtd xml file.
So the content dir is about all content, that Forrest *may* alter.
The raw dir is about content that Forrest may *not* alter in any way.