OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

Mail Index message

[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>


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/




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



-----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-----



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/




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




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
>
>
>
>






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




>>>>> 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.




>>>>> 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.




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/




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/




is anyone using docbook to encode documentation for clos-based systems?

...




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




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ä




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





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

PGP signature



>>>>> 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...:-)



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/




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
> 



>>>>> 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...:-)



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/




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



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