[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: docbook-digest Digest #194
Re: DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: Re: marking up keycaps according to their semantics DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: Re: marking up keycaps according to their semantics DOCBOOK: No attribute value 'PDF' in imagedata Re: DOCBOOK: No attribute value 'PDF' in imagedata Re: DOCBOOK: No attribute value 'PDF' in imagedata DOCBOOK: Re: marking up keycaps according to their semantics DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: Re: marking up keycaps according to their semantics DOCBOOK: using docbook for CLOS Re: DOCBOOK: No attribute value 'PDF' in imagedata DOCBOOK: Image scaling in percent with fop Re: DOCBOOK: using docbook for CLOS DOCBOOK: sgml vs xml DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: sgml vs xml DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: Re: marking up keycaps according to their semantics Re: DOCBOOK: sgml vs xml Re: DOCBOOK: No attribute value 'PDF' in imagedata ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
- From: Tobias Reif <tobiasreif@pinkjuice.com>
- Date: Thu, 06 Mar 2003 00:12:28 +0100
Bob > Perhaps some keycap elements will be empty and > have a function attribute instead. Forgot to add that to the RFE ... (the examples there have content); but in http://lists.oasis-open.org/archives/docbook/200303/msg00029.html there is an empty example. I think that empty elements like <keycap function="shift"/> <keycap function="control"/> or <input type="shift"/> make most sense; the rendering is left to the stylesheet. Tobi -- http://www.pinkjuice.com/
- From: Bob Stayton <bobs@sco.com>
- To: Tobias Reif <tobiasreif@pinkjuice.com>
- Date: Wed, 05 Mar 2003 15:10:20 -0800
On Wed, Mar 05, 2003 at 11:51:21PM +0100, Tobias Reif wrote: > Steinar Bang wrote: > > > >> <keycombo action="simul"> > >> <keycap function="control"/> > >> <keycap>h</keycap> > >> </keycombo> > >> > > When I read Bob Stayton's suggestion earlier in the thread, I thought > > <keycap function="control">h</keycap> > > was what he meant...? > > I don't know what Bob meant, but the above is not a very clear way to > describe the input action, IMHO. I meant what Tobias suggests above: one <keycap> per key. Perhaps some keycap elements will be empty and have a function attribute instead. Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: bobs@sco.com
- From: Norman Walsh <ndw@nwalsh.com>
- To: docbook@lists.oasis-open.org
- Date: Wed, 05 Mar 2003 20:50:35 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 / Tobias Reif <tobiasreif@pinkjuice.com> was heard to say: |> But the truth of the matter is, I'm not sure this information is worth |> marking up in this level of detail. I'd probably use something much simpler. | | I think that it's great if there's the possibility to do it in a | simple way, but also go with very granular and detailed markup if | that's needed. I was implicitly saying that I don't generally see value in trying to capture that level of detail. |> What if you want to do something more interesting, like test your |> source to make sure the quick reference includes all the keyboard |> commands actually used. | | This requires that the testing tools knows what markup to expect for | control, alt, etc. Otherwise, it has to be told that in this document, | "Ctrl" stands for control input, but in this other doc, "C" stands for | control input. As soon as this tool gets fed a third document, it | might not work, since it might use "Strg". It only works if documents are consistently marked up. |> Well, I think I'd be tempted to recognize <keycap>Ctrl</keycap> | | What if authors used "C-" (Emacs notation) or "Strg" (German key | label) or "<C->" (Vim notation)? What if this tool is to be general, | and has gets fed something other than <keycap>Ctrl</keycap> for | control? It only works if documents are consistently marked up. :-) |> and |> translate it directly into another language without adding more markup |> to make it more "semantic". | | I see the latter as necessity. DocBook is mostly (should be 100% IMHO) | about nothing but about being semantic. If I could markup input as Right. But there's a constant tension between ease of markup and granularity of information. Be seeing you, norm - -- Norman Walsh <ndw@nwalsh.com> | You cannot step twice into the http://www.oasis-open.org/docbook/ | same river, for other waters are Chair, DocBook Technical Committee | continually flowing in.--Heraclitus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/> iD8DBQE+ZqlrOyltUcwYWjsRAoJ0AJ9JaA8q4Qising5fPfnCF97Q1aN2gCgj9rR u32/yzHMFQNkYtStypUZOgo= =xezi -----END PGP SIGNATURE-----
- From: Tobias Reif <tobiasreif@pinkjuice.com>
- To: docbook@lists.oasis-open.org
- Date: Thu, 06 Mar 2003 10:02:06 +0100
Norman Walsh wrote: > I was implicitly saying that I don't generally see value in trying to > capture that level of detail. But my proposal doesn't really change the level of detail; it just would allow authors to shift from marking up ASCII rendering (presentational) to marking up the input item (semantic), in a uniform way (specified by the official DTD and spec). Only when such a uniform way is offered can authors expect their documents to work with general tools, and only then can implementers/customizers/users expect their tools to work with any DocBook document. (The spec could also specify that <keycap>Ctrl</keycap> stands for the control key, etc.) > It only works if documents are consistently marked up. Exactly. But many of the DocBook tools (eg your XSLTs) work well with any DocBook document. In the case of input such as control, alt, etc, there currently is no way for a tool to be general. A local tool will work for a local set of consistently marked up documents, but can't be known to work with other documents. With my proposal, all DocBook documents would use the same markup for the same input item, thus general tools could handle them. All documents could be consistently marked up, not just a local set. > | What if authors used "C-" (Emacs notation) or "Strg" (German key > | label) or "<C->" (Vim notation)? What if this tool is to be general, > | and has gets fed something other than <keycap>Ctrl</keycap> for > | control? > > It only works if documents are consistently marked up. :-) But neither the DTD nor the spec specifies what to use for control/alt/etc input. There is no way for a general tool to know what to expect. If I use your XSLTs, there's no way for them or my customization layer to use a pic for all control-foo sequences, unless I tell it what a certain (set of) document(s) uses as ASCII rendering. The next day I receive a new document, and the mechanism stops to work if they used some other ASCII rendering, which is very possible, common, valid, and sensible (C is just as valid and sensible as ctrl). > | I see the latter as necessity. DocBook is mostly (should be 100% > | IMHO) > | about nothing but about being semantic. If I could markup input as > > Right. But there's a constant tension between ease of markup and > granularity of information. How does my proposal make authoring / marking up less easy? My proposal would add value without requiring authors to write more code. In many cases, it even saves some typing. As you say, often trade-offs have to be balanced betweeen higher granularity and added verbosity. But what's the disadvantage in this case? All that's needed is a simple enumerated attribute for keycap, and documents don't become more verbose. It's not a shift to a higher level of granularity and verbosity, but instead it is a shift from arbitrary and non-standardized presentational markup to concise and standardized semantic markup. Tobi -- http://www.pinkjuice.com/
- From: Joachim Ziegler <ziegler@mpi-sb.mpg.de>
- To: "docbook@lists.oasis-open.org" <docbook@lists.oasis-open.org>
- Date: Thu, 06 Mar 2003 15:45:12 +0100
Hello, I've just tried the following from Bob Staytons 2using the XSLT Stylesheets": Example 16.1. Multiple graphics in a mediaobject <mediaobject id="MousePicture"> <imageobject role="html"> <imagedata format="PNG" fileref="mouse.png"/> </imageobject> <imageobject role="fo"> <imagedata format="PDF" fileref="mouse.pdf"/> </imageobject> </mediaobject> But xmllint says: validity error: Value "PDF" for attribute format of imagedata is not among the enumerated set and nsgmls says: value of attribute "format" cannot be "PDF"; must be one of "BMP", "CGM-CHAR", "CGM-BINARY", "CGM-CLEAR", "DITROFF", "DVI", "EPS", "EQN", "FAX", "GIF", "GIF87a", "GIF89a", "JPG", "JPEG", "IGES", "PCX", "PIC", "PNG", "PS", "SGML", "TBL", "TEX", "TIFF", "WMF", "WPG", "SVG", "linespecific" I am using PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" So what is the preferred way of including scalable vector graphics for PDF output? Greetings, Joachim
- From: Jeff Biss <jeff@marco-inc.com>
- To: Joachim Ziegler <ziegler@mpi-sb.mpg.de>
- Date: Thu, 06 Mar 2003 09:32:26 -0600
Joachim, First: do you have Acrobat 4.0 or later? Because it appears that the format allows EPS (not PDF) I would suggest that you produce EPS format images for your publications. Using Acrobat 4.0 allows you to Export a PDF format file to EPS using the File/Export/PostScript or EPS menu item. Therefore you can do the following: 1. Launch Acrobat 4 (or later) 2. Crop the image if required. 3. Click File/Export/PostScript or EPS 4. Click Save on the Export PostScript or EPS Oprions window 5. Provide the desired file name and path in the Export PS - Specify EPS File Name window. This will save the EPS format file and leave the original PDF format file alone. I have not included EPS format files in my XML output so I cannot vouch for its support. Someone else will have to answer that question. Sincerely, Jeff Biss Joachim Ziegler wrote: > Hello, > > I've just tried the following from Bob Staytons 2using the XSLT > Stylesheets": > > Example 16.1. Multiple graphics in a mediaobject > > <mediaobject id="MousePicture"> > <imageobject role="html"> > <imagedata format="PNG" fileref="mouse.png"/> > </imageobject> > <imageobject role="fo"> > <imagedata format="PDF" fileref="mouse.pdf"/> > </imageobject> > </mediaobject> > > > > But xmllint says: > > validity error: Value "PDF" for attribute format of imagedata is not > among the enumerated set > > > and nsgmls says: > > value of attribute "format" cannot be "PDF"; must be one of "BMP", > "CGM-CHAR", "CGM-BINARY", "CGM-CLEAR", "DITROFF", "DVI", "EPS", "EQN", > "FAX", "GIF", "GIF87a", "GIF89a", "JPG", "JPEG", "IGES", "PCX", "PIC", > "PNG", "PS", "SGML", "TBL", "TEX", "TIFF", "WMF", "WPG", "SVG", > "linespecific" > > > I am using > > PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" > > > So what is the preferred way of including scalable vector graphics for > PDF output? > > > Greetings, > Joachim > > > >
- From: Stefan Seefeld <seefeld@sympatico.ca>
- To: "docbook@lists.oasis-open.org" <docbook@lists.oasis-open.org>
- Date: Thu, 06 Mar 2003 10:39:18 -0500
Joachim Ziegler wrote: > Hello, > > I've just tried the following from Bob Staytons 2using the XSLT > Stylesheets": > > Example 16.1. Multiple graphics in a mediaobject > > <mediaobject id="MousePicture"> > <imageobject role="html"> > <imagedata format="PNG" fileref="mouse.png"/> > </imageobject> > <imageobject role="fo"> > <imagedata format="PDF" fileref="mouse.pdf"/> > </imageobject> > </mediaobject> > > > > But xmllint says: > > validity error: Value "PDF" for attribute format of imagedata is not > among the enumerated set hmm, the xsl package seems to allow/expect PDF images (with suitable extensions enabled), so I don't understand why 'PDF' isn't a valid format attribute. For example, fo/graphics.xsl contains this: <xsl:param name="graphic.notations"> <!-- n.b. exactly one leading space, one trailing space, and one inter-word space --> <xsl:choose> <xsl:when test="$passivetex.extensions != 0"> <xsl:text> PNG PDF JPG JPEG linespecific </xsl:text> </xsl:when> <xsl:when test="$fop.extensions != 0"> <xsl:text> SVG PNG PDF JPG JPEG linespecific </xsl:text> </xsl:when> <xsl:when test="$arbortext.extensions != 0"> <xsl:text> PNG PDF JPG JPEG linespecific GIF GIF87a GIF89a TIFF BMP </xsl:text> </xsl:when> <xsl:when test="$xep.extensions != 0"> <xsl:text> SVG PNG PDF JPG JPEG linespecific GIF GIF87a GIF89a TIFF BMP </xsl:text> </xsl:when> <xsl:otherwise> <xsl:text> PNG PDF JPG JPEG linespecific GIF GIF87a GIF89a TIFF BMP </xsl:text> </xsl:otherwise> </xsl:choose> </xsl:param> which seems to imply that all the above extensions support pdf inclusions. Regards, Stefan
- From: Steinar Bang <sb@dod.no>
- To: docbook@lists.oasis-open.org
- Date: Thu, 06 Mar 2003 20:35:35 +0100
>>>>> Tobias Reif <tobiasreif@pinkjuice.com>: [snip!] > Here's the RFE: > http://sourceforge.net/tracker/index.php?func=detail&aid=697374&group_id=21935&atid=384107 I've read it, and I basically agree with the proposal. BTW I don't know if you've seen it, but there's a comment at the end of the RFE, requesting DTD changes for this proposal.
- From: Steinar Bang <sb@dod.no>
- To: docbook@lists.oasis-open.org
- Date: Thu, 06 Mar 2003 20:36:03 +0100
>>>>> Tobias Reif <tobiasreif@pinkjuice.com>: >> Perhaps some keycap elements will be empty and have a function >> attribute instead. [snip!] > I think that empty elements like > <keycap function="shift"/> > <keycap function="control"/> > or > <input type="shift"/> > make most sense; the rendering is left to the stylesheet. An advantage of using a different element from <keycap>, is that you can declare it with a content model of EMPTY, making DTD-aware editors like eg. psgml treat it as an empty element. I don't think <input> is a good choice of element name, though. It gives me HTML form vibes. Not sure what would be a good name, though. <funckey> perhaps? <moderatorkey>? The disadvantage is, as always, adding one more to the already large DocBook element list.
- From: Tobias Reif <tobiasreif@pinkjuice.com>
- To: Steinar Bang <sb@dod.no>
- Date: Thu, 06 Mar 2003 20:49:49 +0100
Steinar Bang wrote: >>>>>>Tobias Reif <tobiasreif@pinkjuice.com>: > I've read it, and I basically agree with the proposal. Great! > BTW I don't know if you've seen it, but there's a comment at the end > of the RFE, requesting DTD changes for this proposal. I've seen it, then posted the detailed description, with which I hope to have satisfied the request you cite. See section "I propose to extend the DTD so that I can write: [...]". Tobi -- http://www.pinkjuice.com/
- From: Tobias Reif <tobiasreif@pinkjuice.com>
- To: Steinar Bang <sb@dod.no>
- Date: Thu, 06 Mar 2003 21:11:41 +0100
Steinar Bang wrote: > An advantage of using a different element from <keycap>, is that you > can declare it with a content model of EMPTY, making DTD-aware editors > like eg. psgml treat it as an empty element. I see. I think it's best to supply user-overridable default renderings in the transformation tools, so supplying none in the doc itself (not allowing content) would be OK from my POV. > I don't think <input> is a good choice of element name, though. I didn't give much thought to it; there probably are many different names which would be as good or better. > It gives me HTML form vibes. It didn't give me those, and I think any name could bring strange connotations for someone. > Not sure what would be a good name, > though. <funckey> perhaps? <moderatorkey>? Some computer users don't use keys to enter input; but since it's the most common input device, perhaps it's OK. funckey sounds good then, or perhaps commandkey, or actionkey. But then I'd tend to stay with keycap, allow it to be empty, and add an attribute. Perhaps <action type="arrow-up"/>, <action type="esc"/> or <nonchar name="control"/> or <control name="shift"/> ... > The disadvantage is, as always, adding one more to the already large > DocBook element list. Specifying an attribute for keycap with an enumerated list of values would be the smallest DTD change. But adding one new element might not bee a change of too large dimensions, and might be clearer. Tobi -- http://www.pinkjuice.com/
- From: james anderson <james.anderson@setf.de>
- To: docbook@lists.oasis-open.org
- Date: Thu, 06 Mar 2003 18:20:13 +0100
is anyone using docbook to encode documentation for clos-based systems? ...
- From: Bob Stayton <bobs@sco.com>
- To: Stefan Seefeld <seefeld@sympatico.ca>
- Date: Thu, 06 Mar 2003 09:06:35 -0800
On Thu, Mar 06, 2003 at 10:39:18AM -0500, Stefan Seefeld wrote: > > Joachim Ziegler wrote: > > Hello, > > > > I've just tried the following from Bob Staytons 2using the XSLT > > Stylesheets": > > > > Example 16.1. Multiple graphics in a mediaobject > > > > <mediaobject id="MousePicture"> > > <imageobject role="html"> > > <imagedata format="PNG" fileref="mouse.png"/> > > </imageobject> > > <imageobject role="fo"> > > <imagedata format="PDF" fileref="mouse.pdf"/> > > </imageobject> > > </mediaobject> > > > > > > > > But xmllint says: > > > > validity error: Value "PDF" for attribute format of imagedata is not > > among the enumerated set > > > hmm, the xsl package seems to allow/expect PDF images (with suitable > extensions enabled), so I don't understand why 'PDF' isn't a valid > format attribute. > > For example, fo/graphics.xsl contains this: > > > <xsl:param name="graphic.notations"> > <!-- n.b. exactly one leading space, one trailing space, and one > inter-word space --> > <xsl:choose> > <xsl:when test="$passivetex.extensions != 0"> > <xsl:text> PNG PDF JPG JPEG linespecific </xsl:text> > </xsl:when> > <xsl:when test="$fop.extensions != 0"> > <xsl:text> SVG PNG PDF JPG JPEG linespecific </xsl:text> > </xsl:when> > <xsl:when test="$arbortext.extensions != 0"> > <xsl:text> PNG PDF JPG JPEG linespecific GIF GIF87a GIF89a TIFF > BMP </xsl:text> > </xsl:when> > <xsl:when test="$xep.extensions != 0"> > <xsl:text> SVG PNG PDF JPG JPEG linespecific GIF GIF87a GIF89a > TIFF BMP </xsl:text> > </xsl:when> > <xsl:otherwise> > <xsl:text> PNG PDF JPG JPEG linespecific GIF GIF87a GIF89a TIFF > BMP </xsl:text> > </xsl:otherwise> > </xsl:choose> > </xsl:param> > > which seems to imply that all the above extensions support pdf > inclusions. This looks like a case of the stylesheets being ahead of the DTD. PDF should be added to the %notation.class; parameter entity in the DTD, so I'll submit an RFE for that. In the meanwhile, you can extend the list in notation.class using local.notation.class to allow PDF by adding this to your DOCTYPE in each file: <!DOCTYPE book PUBLIC "..." "..." [ <!ENTITY % local.notation.class "| PDF"> ]> That should enable validation. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: bobs@sco.com
- From: "simon.rutishauser" <simon.rutishauser@gmx.ch>
- To: docbook@lists.oasis-open.org
- Date: Thu, 06 Mar 2003 12:11:12 +0100
hi, I tried to get my Screenshots scaled to 60% size for pdf output with fop. Actually it doesn't really work. Scaling only works with hard-coded sizes (e.g. 170 pixels or so) but not with percents. Does anybody know how I get this working? Peschmä
- From: Henrik Motakef <henrik.motakef@web.de>
- To: james anderson <james.anderson@setf.de>
- Date: Thu, 06 Mar 2003 23:05:20 +0100
james anderson <james.anderson@setf.de> writes: > is anyone using docbook to encode documentation for clos-based systems? The SBCL folks use docbook for their documentation, maybe one of them can help. IIRC, they are not all too happy with it, and CLOS might be a reason why. Incidentally, I recently started to think about extending docbook to be a better fit for CL documentation, but a) I don't know if it's a good idea yet, b) I don't really have anything to show (I'm not exactly a docbook god, a cl-docbook would serve the two goals of helping me document CL stuff and learning more about docbook at the same time for me). Regards Henrik
- From: Ben Hratshorne <docbook@green.hartshorne.net>
- To: docbook@lists.oasis-open.org
- Date: Thu, 06 Mar 2003 17:28:58 -0800
Hi all, I was wondering a while ago whether to start my docbook project stuff using dsssl or xml. I read around and looked several places, and pretty much everywhere, all I could find was 'they're mostly similar and my example here should work with both.' Lurking on this list for a bit it seems that 90% of the questions are answered with XML syntax. Is it the case that though nobody really seems to say so everyone actually uses XML? I started out using SGML, but havn't really done anything terribly fancy yet (except suppress <p> tags within <ul> tags in HTML output). If there was any time to change, it'd be now. Comments? -ben -- Ben Hartshorne email: ben@hartshorne.net http://ben.hartshorne.net
- From: Steinar Bang <sb@dod.no>
- To: docbook@lists.oasis-open.org
- Date: Fri, 07 Mar 2003 08:13:25 +0100
>>>>> Tobias Reif <tobiasreif@pinkjuice.com>: [snip!] > Perhaps > <action type="arrow-up"/>, <action type="esc"/> > or > <nonchar name="control"/> > or > <control name="shift"/> ... I think it would be clearer if the new element has "key" in its name, ie. <actionkey type="arrow-up"/>, <actionkey type="esc"/> or <controlkey name="shift"/> ... [snip!] > Specifying an attribute for keycap with an enumerated list of values > would be the smallest DTD change. > But adding one new element might not bee a change of too large > dimensions, and might be clearer. Since both sides have merit, I guess you will just have to pick one for your proposed DTD changes for the RFE...:-)
- From: Tobias Reif <tobiasreif@pinkjuice.com>
- To: Steinar Bang <sb@dod.no>
- Date: Fri, 07 Mar 2003 09:49:23 +0100
Steinar Bang wrote: > I think it would be clearer if the new element has "key" in its name But then I'd tend to stay with keycap, allow it to be empty, and add an attribute. > Since both sides have merit, I guess you will just have to pick one > for your proposed DTD changes for the RFE...:-) I leave that decision to the TC. My request would be satisfied with either way. In the RFE, there is: [...] or merely add an attribute to the DTD: <keycombo action="simul"> <keycap function="control">Ctrl</keycap> <keycap>h</keycap> </keycombo> [and I added] It should be allowed for to the control key element to be empty: <keycombo action="simul"> <keycap function="control"/> <keycap>h</keycap> </keycombo> So the change in the DTD would merely be to allow keycap to be empty, and add an attribute. Tobi -- http://www.pinkjuice.com/
- From: Camille =?UNKNOWN?Q?B=E9gnis?= <camille@mandrakesoft.com>
- To: Ben Hratshorne <docbook@green.hartshorne.net>
- Date: Fri, 07 Mar 2003 10:43:50 +0100
Hi Ben, I think the situation is the following: SGML is the legacy system most people get on using because it allows acceptable print output. For HTML output this is not true as XSL allows for efficient rendering. Now if most discussions are around XML and not SGML it is because XML evolves fast, gradually replacing SGML implementations. This is notably possible thanks to the maturity of FOP processors. On the other hand SGML applications are not evolving anymore, hence less discussions. Camille. On Thu, 06 Mar 2003 17:28:58 -0800 "Ben Hratshorne" <docbook@green.hartshorne.net> wrote: > Hi all, > > I was wondering a while ago whether to start my docbook project stuff > using dsssl or xml. I read around and looked several places, and pretty > much everywhere, all I could find was 'they're mostly similar and my > example here should work with both.' > > Lurking on this list for a bit it seems that 90% of the questions are > answered with XML syntax. Is it the case that though nobody really > seems to say so everyone actually uses XML? > > I started out using SGML, but havn't really done anything terribly fancy > yet (except suppress <p> tags within <ul> tags in HTML output). If > there was any time to change, it'd be now. > > Comments? > > -ben > > -- > Ben Hartshorne > email: ben@hartshorne.net > http://ben.hartshorne.net >
- From: Steinar Bang <sb@dod.no>
- To: docbook@lists.oasis-open.org
- Date: Fri, 07 Mar 2003 10:44:08 +0100
>>>>> Tobias Reif <tobiasreif@pinkjuice.com>: > But then I'd tend to stay with keycap, allow it to be empty, and add > an attribute. Empty <keycap> elements is already allowed by today's DTD. Remember, <keycap/> is just the same as <keycap></keycap>. The reason I might wish for a different element with an EMPTY content model, is to make psgml (and other DTD aware editors) just insert an <functionkey/> element instead of an <keycap></keycap> when I press C-c C-e. And I would agree that this reason may not be a very good reason to add to the complexity of DocBook...:-)
- From: Tobias Reif <tobiasreif@pinkjuice.com>
- To: Steinar Bang <sb@dod.no>
- Date: Fri, 07 Mar 2003 10:48:33 +0100
Steinar Bang wrote: > Empty <keycap> elements is already allowed by today's DTD. I see. Then all that's left is to add an attribute :) (the name might be "function", "control", "action", or etc) > Remember, <keycap/> is just the same as <keycap></keycap>. sure > The reason I might wish for a different element with an EMPTY content > model, is to make psgml (and other DTD aware editors) just insert an > <functionkey/> > element instead of an > <keycap></keycap> > when I press C-c C-e. > > And I would agree that this reason may not be a very good reason to > add to the complexity of DocBook...:-) yep, tools come after the lang IMHO (where trade-offs have to be made) Tobi -- http://www.pinkjuice.com/
- From: Jirka Kosek <jirka@kosek.cz>
- To: Camille Bégnis <camille@mandrakesoft.com>
- Date: Fri, 07 Mar 2003 10:53:10 +0100
Camille Bégnis wrote: > I think the situation is the following: SGML is the legacy system most people get on using because it allows acceptable print output. This is not quite truth. With SGML you are mostly using DSSSL stylesheets and toolchain which has quite good print output. But this toolchain (DSSSL + Jade/OpenJade) can be used also with XML sources. -- ----------------------------------------------------------------- Jirka Kosek e-mail: jirka@kosek.cz http://www.kosek.cz
- From: Joachim Ziegler <ziegler@mpi-sb.mpg.de>
- To: Bob Stayton <bobs@sco.com>
- Date: Fri, 07 Mar 2003 13:05:15 +0100
Bob Stayton wrote: > In the meanwhile, you can extend the list in notation.class > using local.notation.class to allow PDF by adding this to your > DOCTYPE in each file: > > <!DOCTYPE book PUBLIC "..." "..." [ > <!ENTITY % local.notation.class "| PDF"> > ]> > > That should enable validation. It seems that xmllint can't handle that extension: /opt/gnu/bin/xmllint -valid --noout LEDATutorium.xml LEDATutorium.xml:44: validity error: NOTATION attribute application reference an unknown notation "PDF" <book lang="de"> ^ chapter1.xml:6: validity error: NOTATION attribute application reference an unknown notation "PDF" <chapter> ^ (using libxml version 20412) This is a different error message from what I get without the above extension: /opt/gnu/bin/xmllint -valid --noout LEDATutorium.xml LEDATutorium.xml:752: validity error: Value "PDF" for attribute format of imagedata is not among the enumerated set <imagedata align="center" format="PDF" fileref="Pictures/ArrayOfChar.pdf ^ nsgmls reports the file as valid now.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Powered by ezmlm-idx