If you look at the code and projects using it, yes, I am aware of this. Or did you miss the directories containing the font definitios tongue-in-cheekly named "no-idea-what-to-do-with-these-yet"? ;)
Actually I was leaning on the expertise of the Red Hat documentation team here, since DocBook (nor xslt, really) is not my forte. I have yet to breach this particular topic with them. If you have a particular need/requirement, well, patches welcome ;) On Thu, 2007-06-07 at 13:15 +0200, Tamás Cservenák wrote: > Hello, > > I had another problem with docbook plugins for maven2. I will just describe > it, as it is too often overseen :) > > My problem was FOP and it's configuration in docbkx plugin. I needed docbook > in maven2 to generate docs in Hungarian language. The FOP per default > produces PDF with Adobe Default font set (16 fonts) and with all of them in > LATIN1 encoding, which is not enough for Eastern European languages. > > The resolution is to "introduce" different fonts beside defaults to FOP. > See: > http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#register > > Just a thought, since as i read your code, you do the similar thing as > docbkx: > > http://anonsvn.jboss.org/repos/hibernate/trunk/sandbox/maven-poc/plugins/maven-jboss-docbook-plugin/src/main/java/org/jboss/maven/plugin/docbook/gen/render/PdfRenderer.java > > http://docbkx-tools.googlecode.com/svn/trunk/docbkx-maven-plugin/src/main/java/com/agilejava/docbkx/maven/AbstractPdfMojo.java > > > The configuration customization for FOP is unreachable in both cases, thus > it both would renders unusable PDFs in non-LATIN1 environments. > > The solution would be to make FOP configuration reachable from maven config, > or at least create a possibility to direct the FOP to use some specific > config-file from within the project. > > > Btw, the docbkx project moved from agilejava.com to > http://code.google.com/p/docbkx-tools/ > > Cheers, > ~t~ > > > On 6/4/07, Steve Ebersole <[EMAIL PROTECTED]> wrote: > > > > As part of migrating Hibernate to use Maven, one of the big issues I ran > > into was the current state of DocBook plugins for Maven. The current > > mojo-codehaus hosted plugin is insufficient. There is another more > > widely used one done by one Wilfred Springer as part of something called > > "agilejava". The "agilejava" one is fairly full featured, but is really > > pretty bare bones in terms of configuration (its is mainly a simplistic > > wrapper around the defined DocBook xslt parameters). > > > > In my estimation the, "agilejava" one was closer to usability, but Mr. > > Springer did not seem interested in accepting my volunteer to help > > improve his plugin. So I began implementing my own. > > > > It works off of a slightly different approach than the other two. The > > biggest difference being that custom stylesheets are packaged as > > separate projects and included via the Maven dependency mechanism. This > > allows true reuse of the stylesheets across projects. The other is > > planned better support of translations which is important for Hibernate, > > and most projects using DocBook. > > > > This however led to a conceptual question regarding how to best handle > > image references. As background, in DocBook, the way images normally > > get resolved is as via xslt templates. The DocBook supplied templates > > do a hard file lookup relative to a xslt parameter named 'img.src.path' > > if it is set; and really this is format specific as well. Regardless, > > though, I need a mechanism to access the image files from these "style > > projects" and be able to resolve reference to them from the DocBook > > source or xsl stylesheets. I have identified a few potential approaches > > to achieve that: > > 1) force separation of (a) xslt and (b) resources like images/css into > > separate projects. Specifically, #b would need a custom packaging which > > would allow me to find resources and unarchive them locally into a > > staging dir for use in 'img.src.path'. A variation on this would be to > > bundle them together with a custom packaging and somehow extract just > > the "resources". > > 2) Apply custom graphics resolution templates to the built xsl > > transformers, hoping that the custom xslt does not itself do this. > > > > I'm not (necessarily) looking for volunteers (although certainly that is > > welcome). More I just need people's thoughts on the various approaches, > > especially those using or familiar with DocBook. > > > > Thanks, > > Steve > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
