[docbook-apps] customizing the class attribute for sections and olinks
Hi All, I would like to apply custom values of the class attribute to the selected section and olink elements. I've tried with the role attribute, but it does not work. I've also tried to add the following template to my customization layer (both for section and olink): xsl:template match=secti...@role = 'quickref'] mode=class.value xsl:value-of select=@role/ /xsl:template Again, no success. What am I missing? Thanks, Robert
Re: [docbook-apps] customizing the class attribute for sections and olinks
On 18/03/10 09:02, robert wrote: Hi All, I would like to apply custom values of the class attribute to the selected section and olink elements. I've tried with the role attribute, but it does not work. I've also tried to add the following template to my customization layer (both for section and olink): xsl:template match=secti...@role = 'quickref'] mode=class.value xsl:value-of select=@role/ /xsl:template Again, no success. What am I missing? http://docbook.sourceforge.net/release/xsl/current/doc/html/css.decoration.html xsl:param name=css.decoration select=1/xsl:param That takes your element names through to class attributes I believe. regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Saxon: Failed to interpret image: Sketches/Site.svg
Hi there, I recently switch from xsltproc to using saxon (I wanted syntax highlighting). However after the switch saxon keeps complaining about: ... Failed to interpret image: Sketches/Site.svg ... I looked at the output using firefox and everything seems ok. Am I missing something ? Is there an option to remove this warning ? Thanks -- Mathieu - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Google summer of code
On 03/18/2010 12:49 AM, Mike Maxwell wrote: Stefan Seefeld wrote: On 03/14/2010 03:26 PM, Mike Maxwell wrote: My sense (which I guess I've voiced a couple times) is that there is already an awfully lot (too much, IMO) about DB that is specific to programming languages. Our localization has over 200 lines like define name=db.classsynopsisnotAllowed//define My guess is that if you were to add programming elements in a separate namespace, you would want to move all the existing programming-specific elements into that namespace too. I don't think this is possible without breaking lots of existing documentation. If backward-compatibility wasn't an issue, I would very much like the suggestion. Given that the root element of a DocBook 5 file looks something like chapter xmlns=http://docbook.org/ns/docbook;... is this really a problem? Couldn't a DB document written for the new modular DocBook schema have something like chapter xmlns=http://docbook.org/ns/ModDocBook; or chapter xmlns=http://docbook.org/ns/docbook6;... ? So any documentation written in the Olde DB could continue to use the old schema, and not get broken. Sure, DocBook 6 could do that. But such an endeavor is entirely out of scope for the task I'm proposing here, or anything else related to this coming GSoC. You may want to lobby Norm for that. :-) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Public/System doctype IDs misbehaving in Eclipse output (1.73)
On Wed, Mar 17, 2010 at 6:27 PM, David Cramer dcra...@motive.com wrote:
I was never able to get around that (but I don't think it occurred to me
to ask here). I ended up post-processing the plugin.xml and toc.xml
files to remove the doctype.
I'll be interested in hearing if there's a right way. I have a vague
idea/memory that this is a saxon thing.
I ran into the same problem with the ePub stylesheets. Under the hood,
this uses the template named write.chunk. From a quick look at the
SVN trunk, I think you'd want to add two paramaters to the call to
write.chunk that generates these files and overrides the doctype
you're setting elsewhere:
Index: eclipse.xsl
===
--- eclipse.xsl (revision 8582)
+++ eclipse.xsl (working copy)
@@ -114,6 +114,8 @@
xsl:with-param name=encoding select='utf-8'/
xsl:with-param name=indent select='yes'/
xsl:with-param name=quiet select=$chunk.quietly/
+xsl:with-param name=doctype-public select=''/ !--
intentionally blank --
+xsl:with-param name=doctype-system select=''/ !--
intentionally blank --
xsl:with-param name=content
xsl:choose
@@ -207,6 +209,8 @@
xsl:with-param name=encoding select='utf-8'/
xsl:with-param name=indent select='yes'/
xsl:with-param name=quiet select=$chunk.quietly/
+xsl:with-param name=doctype-public select=''/ !--
intentionally blank --
+xsl:with-param name=doctype-system select=''/ !--
intentionally blank --
xsl:with-param name=content
plugin name={$eclipse.plugin.name}
id={$eclipse.plugin.id}
...that said, I've never used the Eclipse output, so this is just a
guess based on what is in SVN...
Keith
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] Capturing phrase books and dictionaries
Lech Rzedzicki wrote: We're trying to keep our markup close to DB5 but we also want to tighten the schema a bit further. One area we're particularly struggling with is phrase books and dictionaries. This was originally modelled using TEI and reflects the actual structure quite well. The problem we have is that both in the original language portion (form) and in the the target language explanation (sense) we need to allow many optional elements such as example, pronunciation, often multiple times (as there can be many forms or senses or many examples for each sense or form), gradually this led us to a very complex and loose model which also doesn't maintain the relationship between the original and translation too well. I was wondering if any of you have any experience dealing with similar content and whether you could share your experience and schemas? We are working a lot with XML-based bilingual dictionaries (not phrase books, although they may be similar). I think the bottom line is, don't use DocBook for dictionaries (at least not for the body of the dictionary, i.e. all the entries). It just isn't the same kind of structure. TEI-encoded dictionaries tend to reflect the structure of the print dictionary from which the electronic form was derived. That has a couple advantages: 1) It's easy(-er) to convert from the print form to the electronic form, and go back later and make sure you did it right 2) It makes producing a new print copy of the dictionary that looks like the original print dictionary easy(-er). It also has some disadvantages: 1) Unless you're working with a bunch of similar dictionaries from a single publisher, you're likely to wind up with a large number of schemas (or DTDs), one for each dictionary, and that can be hard to manage. 2) The large number of schemas in (1) also means that you probably have to write a different CSS (or whatever you use) for each one. 3) You're limited to a single presentation form, i.e. it is difficult to display a root-based dictionary as a stem-based dictionary. What we (and probably most people who work with multiple electronic dictionaries) do instead, is to use a generic lexicon schema. This flattens the overall structure of a typical print dictionary (e.g. subentries become entries on their own); the original structure is instead represented by xrefs (so a sub-entry and a minor entry both have pointers back to the main entry). One can then postpone until run-time decisions like root-based vs. stem-based presentation, or whether a given minor entry is displayed as a sub-entry or as an entry on its own (and perhaps alphabetized on its own, if that's relevant to the electronic display). The run-time decisions are then implemented using one of two (or several) style sheets. More than that about this approach (as opposed to doing something with dictionaries inside DocBook) probably doesn't belong on this list. Fortunately there are lexicography mailing lists, e.g. the Lexicography list (see http://linguistlist.org/lists/get-lists.cfm). -- Mike Maxwell What good is a universe without somebody around to look at it? --Robert Dicke, Princeton physicist - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Saxon: Failed to interpret image: Sketches/Site.svg
| -Original Message- | From: Mathieu Malaterre | | ... | Failed to interpret image: Sketches/Site.svg | ... | |I looked at the output using firefox and everything seems ok. Am I | missing something ? Is there an option to remove this warning ? The warning comes from the Saxon graphic size extension, which does not support SVG images. The only way to remove the warning is to set the graphicsize.extension parameter to 0. Mauritz - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Public/System doctype IDs misbehaving in Eclipse output (1.73)
That addressed the problem quite nicely, thank you very much. I would
have been groping for that for quite a while.
-Original Message-
From: Keith Fahlgren [mailto:abdela...@gmail.com]
Sent: Thursday, March 18, 2010 7:15 AM
To: David Cramer
Cc: Jeff Hooker; DocBook Apps
Subject: Re: [docbook-apps] Public/System doctype IDs misbehaving in
Eclipse output (1.73)
On Wed, Mar 17, 2010 at 6:27 PM, David Cramer dcra...@motive.com
wrote:
I was never able to get around that (but I don't think it occurred to
me
to ask here). I ended up post-processing the plugin.xml and toc.xml
files to remove the doctype.
I'll be interested in hearing if there's a right way. I have a vague
idea/memory that this is a saxon thing.
I ran into the same problem with the ePub stylesheets. Under the hood,
this uses the template named write.chunk. From a quick look at the
SVN trunk, I think you'd want to add two paramaters to the call to
write.chunk that generates these files and overrides the doctype
you're setting elsewhere:
Index: eclipse.xsl
===
--- eclipse.xsl (revision 8582)
+++ eclipse.xsl (working copy)
@@ -114,6 +114,8 @@
xsl:with-param name=encoding select='utf-8'/
xsl:with-param name=indent select='yes'/
xsl:with-param name=quiet select=$chunk.quietly/
+xsl:with-param name=doctype-public select=''/ !--
intentionally blank --
+xsl:with-param name=doctype-system select=''/ !--
intentionally blank --
xsl:with-param name=content
xsl:choose
@@ -207,6 +209,8 @@
xsl:with-param name=encoding select='utf-8'/
xsl:with-param name=indent select='yes'/
xsl:with-param name=quiet select=$chunk.quietly/
+xsl:with-param name=doctype-public select=''/ !--
intentionally blank --
+xsl:with-param name=doctype-system select=''/ !--
intentionally blank --
xsl:with-param name=content
plugin name={$eclipse.plugin.name}
id={$eclipse.plugin.id}
...that said, I've never used the Eclipse output, so this is just a
guess based on what is in SVN...
Keith
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] customizing the class attribute for sections and olinks
Hi Dave, I think you are mistaking 'css.decoration' for some other parameter. If css.decoration is set 1, then a few elements will have a style attribute added to them, but it isn't a general mechanism. The stylesheet by default passes the element name through to the class value. That works ok, but it wasn't very flexible, so starting with version 1.72 the stylesheets added a hook for generating your own class values, with the element name as the fallback. For details see: http://www.sagehill.net/docbookxsl/HtmlCustomEx.html#CustomClassValues With custom class values, you can do a lot more with CSS. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Dave Pawson da...@dpawson.co.uk To: docbook-apps@lists.oasis-open.org Sent: Thursday, March 18, 2010 2:12 AM Subject: Re: [docbook-apps] customizing the class attribute for sections and olinks On 18/03/10 09:02, robert wrote: Hi All, I would like to apply custom values of the class attribute to the selected section and olink elements. I've tried with the role attribute, but it does not work. I've also tried to add the following template to my customization layer (both for section and olink): xsl:template match=secti...@role = 'quickref'] mode=class.value xsl:value-of select=@role/ /xsl:template Again, no success. What am I missing? http://docbook.sourceforge.net/release/xsl/current/doc/html/css.decoration.html xsl:param name=css.decoration select=1/xsl:param That takes your element names through to class attributes I believe. regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
