Re: DOCBOOK-APPS: Rely on CSS?
At 13:39 2003 01 21 +0100, Stefan Priebsch (e-novative) wrote: To me, external CSS is an avantage since - it makes my HTML more compact and more readable - it (more) clearly separates the content/presentation - it allows me to easily hook up a document somewhere else, and make it appear in another CI or Style And it means you can no longer just send a single file to some recipient and have them view the result in a browser. You have to solve the packaging problem. Granted, you have to do this whenever you have a graphic in your document too, but having an external style file does add some complexity. It seems that putting CSS formatting commands into the HTML is just another variant of using deprecated stuff like the FONT tag. Right--so what? We're talking about the case where the source is DocBook XML. We're using HTML as the PDF of the Web. I'm exaggerating a bit (I like clean HTML too), but the point is still there. Using some embedded CSS seems perfectly reasonable when you're creating output (as opposed to the authoritative source). Isn't talking about CSS scrambled into the HTML just throwing away the biggest advantages CSS and HTML together offer? I'd say our advantages accrue from the fact that we are using DocBook XML for our source. The CSS+HTML is the output, not the source. As output, its raison d'etre is to present well. (Yes, this includes being accessible, but use of the style attribute doesn't prevent this.) paul
Re: DOCBOOK-APPS: Is it time to rely on CSS?
At 11:10 2003 01 20 -0800, Bob Stayton wrote: On Mon, Jan 20, 2003 at 01:21:43PM -0500, Norman Walsh wrote: There are more and more bug reports coming in of the form Why are you doing X? You should be using CSS. For example, b elements in figure titles, background color on tables, etc. Even the inline style markup in admonitions falls into this category as, if we relied on CSS, we'd expect an external stylesheet to apply that style. Historically, the stylesheets have tried to walk some sort of a line between relying on CSS and getting reasonable results in browsers that don't support CSS. Is it time to move that line farther out, removing things that could be done with CSS and just expecting CSS to be used? I think this is ok. I'm concerned about the transition. If we are expecting CSS to be used, would we supply a basic CSS stylesheet that implements these changes and gives people the framework for customizing? Bob seems to be inferring that Norm's message implies a standalone stylesheet. But CSS use can happen in three levels: 1. in the style attribute 2. in the style element 3. in a separate stylesheet. There are extra problems with managing standalone stylesheets (much as I appreciate the benefits of separating content and style). I'm not sure what Norm's message was implying--Norm, can you elaborate? paul
Re: DOCBOOK-APPS: Is it time to rely on CSS?
At 14:56 2003 01 20 -0500, ed nixon wrote: In the development and customization of CSS, some people like to work with the styles in the header because it permits slightly more immediate feedback. When the work is done however, it can be nice to be able to move (some or all) of the finished specifications out, to one or more external files. External files raise more problems, so I wouldn't want to move to a solution that requires external files. paul
Re: DOCBOOK-APPS: Norm's catalog article.
At 19:11 2003 01 15 +, Dave Pawson wrote: http://www.arbortext.com/Think_Tank/Norm_s_Column/Issue_Three/body_issue_three.html#N703 Now 404 I had it linked from the faq. Anyone copied it ... elsewhere? I guess his old employers don't want it anymore? regards DaveP Sorry if things got moved at some point, but I think it must have been long ago. I believe it has resided at http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.html for a while now. paul
Re: DOCBOOK-APPS: list items HTML formating with XSL
At 15:29 2003 01 06 -0200, [EMAIL PROTECTED] wrote: I've been overiding several XSL templates in order to get valid XHTML Strict output. ... In the process of overiding the corresponding templates in lists.xsl and block.xsl, I noted that most of the job could be avoided by simply generating the ID attribute inside the li element, instead of generating a empty a element. Is there some reason you used lia id=someid/ap.../p/li instead of the simpler li id=someidp.../p/li You could do that as long as you realize that this does not follow the HTML browser compatibility guidelines at [1] and it won't work with Netscape 4.x browsers. That is, your suggested code matches the specs, but not a lot of the deployed tools out there. paul [1] http://www.w3.org/TR/xhtml1/#C_8
Re: DOCBOOK-APPS: Problems with double-sided print output from xsl
At 14:51 2002 12 10 -0800, Bob Stayton wrote: This looks like FOP is not supporting the FO page-sequence property initial-page-number=auto-odd. The newer versions use that property instead of force-page-count=end-on-even, which FOP did support. I don't know why Norm changed it. initial-page-number is a basic property that all implementations must support whereas force-page-count is an extended property. Also, use of initial-page-number=auto-odd on the initial page that is supposed to be odd (recto) is much more intuitive and better practice than trying to make chapters start on recto pages by trying to make whatever page-sequence might precede a chapter end on an even page. paul
Re: DOCBOOK-APPS: Re: XInclude doesn't validate with xmllint
At 16:00 2002 12 03 +0300, Vitaly Ostanin wrote: On Tue, 03 Dec 2002 07:30:03 -0500 Norman Walsh [EMAIL PROTECTED] wrote: Base URIs have no bearing on ID values. ID values used for linking and must be uniq, right? It is a validation error if there are duplicate IDs in a document. In modular set of docbook/xml after processing XInclude some documents may to have duplicates of ID. True, and this would be a validation error. The same is true if you used external parsed entities. XInclude does nothing to solve the ID uniqueness problem. In particular, if you reuse the same chunk of XML in two places in the same document and any element therein contains an ID, you will end up with a document that is not valid (whether you use external parsed entities or XInclude). I think what using 'xml:base' + 'filename' + 'id' can produce uniq values as result. Maybe, but that isn't how things work in XML. paul
Re: DOCBOOK-APPS: Is bottom baseline alignment of inlinemediaobjectpossible ?
At 21:32 2002 11 28 -0800, Bob Stayton wrote: On Thu, Nov 28, 2002 at 12:36:35PM +0100, Alain NAKACHE wrote: . . . and here is a schema of the result with XLST 1.57.0 + FOP 0.24 : . +-+ Bla, Blahhh, Blahhh, Blahhh, Blahhh, | | +-+ Blahhh, . +-+ Bla, Blahhh, Blahhh, Blahhh, Blahhh, | | +-+ Blahhh, With DSSSL + JadeTex i obtained this result : +-+ | | . +-+ Bla, Blahhh, Blahhh, Blahhh, Blahhh, Blahhh, +-+ | | . +-+ Bla, Blahhh, Blahhh, Blahhh, Blahhh, Blahhh, Is it possible to obtain the same result as DSSSL rendering with XSLT ? Yes, but not with FOP it seems. The default alignment for XSL-FO is for the bottom of the graphics block to be on the baseline of the text, as your DSSSL example produces. The DocBook XSL stylesheets are putting out the correct XSL-FO, but FOP isn't getting it right. When I process the same file with RenderX's XEP, I get the correct baseline alignment that you want. When I run Alain's source through XSLT (using the 1.50 stylesheets), I get the following for the first fo:list-item (with various irrelevant properties elided and the results pretty-printed): fo:list-item fo:list-item-label end-indent=label-end() fo:block#x2022;/fo:block /fo:list-item-label fo:list-item-body start-indent=body-start() fo:block fo:external-graphic src=url(...)/Bla, Blahhh, Blahhh, Blahhh, Blahhh, Blahhh, /fo:block /fo:list-item-body /fo:list-item I agree that the list-item-body should look as you two say it should, but I'm missing why the result shouldn't look more like: . +-+ | | +-+ Bla, Blahhh, Blahhh, Blahhh, Blahhh, Blahhh, with the list-item-label (the bullet) aligning nearer the top of the graphic. 6.8.3 fo:list-item says [1]: The children of each normal area returned by an fo:list-item formatting object returned by the fo:list-item-label and fo:list-item-body objects are positioned in the block-progression-direction with respect to each other according to the relative-align trait. and 7.13.6 relative-align [2] indicates that the initial value for relative-align is before which means: the before-edge of the first area descendant generated by the fo:list-item-label is placed coincident with the before-edge of the area generated by the fo:list-item. Similarly the before-edge of the first area descendant generated by the fo:list-item-body is placed coincident with the before-edge of the area generated by the fo:list-item. Assuming a line-stacking-strategy of max-height (which is the default), doesn't that all mean that the result should have the bullet aligned nearer the top of the graphic? paul [1] http://www.w3.org/TR/xsl/slice6.html#fo_list-item [2] http://www.w3.org/TR/xsl/slice7.html#relative-align
Re: DOCBOOK-APPS: line before footnote area
I think what's desired is theoretically doable using
an fo:static-content formatting object with a flow-name
property value of xsl-footnote-separator.
See the last paragraph in section 6.4.1.4 of the XSL spec.
However, not all XSL-FO implementations support this.
paul
At 13:12 2002 11 12 -0800, Bob Stayton wrote:
On Wed, Nov 06, 2002 at 02:18:47PM +0100, Marko Petersen wrote:
Hi,
I am trying to add a line between the main-reference-area and
the footnote-reference-area in the PDF output. Has anybody an
idea how to do this?
I don't see any way to do this. When a footnote element
is processed, the following fo objects are placed in the fo file:
fo:footnote
fo:inlinemark/fo:inline
fo:footnote-body font-size={$footnote.font.size}
[apply templates to the footnote element]
/fo:footnote-body
/fo:footnote
While you could put a top border property on the
fo:footnote-body or a block within it, that would apply to
every footnote, not just the first one on the page.
Since the FO processor takes the fo:footnote-body elements
and makes the decision about on which page to place them,
there is no way for the stylesheet to designate the
first footnote on a page that should have a top border.
And I don't see a way to tell the FO processor to
do that, either.
Does anyone else have a solution?
Are there any other 'hooks' for processing footnotes?
--
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: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
At 10:12 2002 11 08 -0800, Bob Stayton wrote: I had some further correspondence with Norm about this problem. It turns out that relative system ids can't be resolved by the Java resolver classes because they never even see them in their original form. He explained that the SAX API resolves a relative system id such as docbookx.dtd as relative to the document's directory. The SAX API changed docbookx.dtd to file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd in the parsing stage. That's why the resolver reports: resolveSystem(file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd) instead of: resolveSystem(docbookx.dtd) He says there is no hook for the resolver classes to get the original docbookx.dtd string for the resolver to look up in the catalog. He says he argued against this behavior at the time, but lost. To put a sharper point on it, SAX is broken. When Norm tried to explain why and have it fixed, whoever all gets to make the decision decided to leave SAX broken. It's a real shame. There are tools (that don't use SAX to resolve external entities) that do work correctly. paul
Re: DOCBOOK-APPS: questions about XML catalogs?
At 12:06 2002 11 02 -0500, Robert P. J. Day wrote: On Sat, 2 Nov 2002, Mark Johnson wrote: On Saturday, November 2, Robert P. J. Day wrote: if one has queries about XML catalogs, where's the best place to ask? I'm not sure of the policy of Docbook-apps. There is a public OASIS mailing list for catalogs. However, Norm and I are on this list, and we are two of the key people behind catalogs. i'm reading the doc on XML catalogs at OASIS, and the terminology is just a tad confusing. first, what's a catalog? according to the doc, it's a *logical* structure that contains mapping information. IOW, it's just a hypothetical structure of some kind, not necessarily a file or collection of files, but it could consist of multiple files. or it could be a database of some kind. or whatever. so far, so good? Right. The spec seems pretty clear here. a catalog entry file, OTOH, is a physical document that contains a set of catalog entries. Yes, again I think the spec says this clearly. The spec tries to use catalog and catalog entry file pretty carefully (perhaps with the exception of the element names themselves as you note). and if you look in a catalog entry file, apparently, the root element must be a catalog entry. it seems that this is an unfortunate element name, since the contents of a catalog entry file are, technically, not a catalog. it seems just a bit recursive. You are correct that we abbreviated some of the element names. The element name should probably have been catalogEntryFile, but we opted for the shorter catalog instead. Note that the entries in a catalog-entry-file are also catalog entries (since they are entries in the logical catalog). further, we read that catalog entries can be of type delegatePublic, delegateSystem and so on, as well as catalog, even though all of the other entries (as i read it) must occur within a catalog element. I think you have a misunderstanding here, but I'm not entirely sure what you're thinking. Note: The catalog entry is the root of a catalog entry file. All other entries occur within this catalog element. Is there something else you're thinking here? so is a catalog itself a catalog entry type? Um, sure, I guess. It's an entry in a catalog. I guess I'm not sure I understand your real question. (side question: does the file /etc/xml/catalog, by itself, represent a catalog, or just a catalog entry file? yes, i'm being incredibly nitpicky.) [I don't know if you're referring to a specific /etc/xml/catalog, but I'm assuming not.] It is certainly a catalog entry file. It could certainly be a catalog. Whether it is a catalog in a specific situation depends on what you've told the application to use for a catalog. Note: The catalog is effectively an ordered list of (one or more) catalog entry files. It is up to the application to determine the ordered list of catalog entry files to be used as the logical catalog. and i read that the nextCatalog entry does not seem to refer to another catalog, but another catalog entry file, which has been clearly defined by now to not mean the same thing. Correct. So I gather your issue is just the name nextCatalog. If it helps, pretend we called it nextCatalogEntryFile but are allowing nextCatalog as an abbreviation. anyway, i hope you get the idea. i was just skimming that document and was just getting more and more puzzled by the terminology. can anyone clarify this? or am i making too much of this? rday Other than the element names catalog and nextCatalog themselves, if you find a use of catalog versus catalog entry file in the spec that seems wrong to you, please let us know. paul
RE: DOCBOOK-APPS: RE: XML catalog resolution problems
At 12:27 2002 10 30 +0100, Jeanson Mauritz wrote: When trying xsltproc, I found that it accepts and resolves system entries for stylesheets in catalog files. As I take it, this is not the correct behaviour. You are correct, xsltproc is not in compliance with the XML Catalog spec. The XML Catalog spec makes it clear that system entries are for resolving external identifiers (production 75 in XML) and clearly says about URI entries [1]: 4.2. URI Entries Other URI references, for example namespace names, stylesheets, included files, graphics, and hypertext references, simply identify other resources. The input to a resolver that locates resources is simply the original URI reference. For the purposes of resolving URI references, the following entries are considered: The uri entry indicates that an entity manager must use the associated URI reference to locate the resource. The rewriteURI entry ... The delegateURI entry ... Section 7 Catalog Resolution Semantics has two sections, one each describing External Identifier Resolution and URI Resolution in great detail. Again it is made clear that system entries are only for resolving external identifiers and cannot be used for resolving other URIs such as those for stylesheets. It is wrong to use the system entries to resolve other URI references [such as] stylesheets I believe Daniel Veillard is well aware of this, but he disagrees with the XML Catalog spec in this regard and has therefore written xsltproc to do what he thinks it should instead of to be compliant with the OASIS Committee Specification. If you want to write XML catalogs that comply with the spec and work interoperably in compliant implementations, you would be wise to use the system and uri entry types accordingly. paul [1] http://www.oasis-open.org/committees/entity/spec.html#s.uri.ent [2] http://www.oasis-open.org/committees/entity/spec.html#s.semantics
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
At 11:12 2002 10 30 -0500, Daniel Veillard wrote: On Wed, Oct 30, 2002 at 09:28:44AM -0600, Paul Grosso wrote: The XML Catalog spec makes it clear that system entries are for resolving external identifiers (production 75 in XML) and clearly says about URI entries [1]: And I have said to the XML Catalog comitee that an URI Reference is an URI-Reference and that having to distinguish arbitrarilly one done from a DOCTYPE entry from one done from an xi:include href entry doesn't make any sense to me, and that I would not support the distinction in my software unless getting a meaningful reason to distinguish those. I haven't received any justification yet from the commitee about the reason to distinguish those exept they are different, no sorry ... Well, when Microsoft said I see no reason not to support empty end tags (i.e., /) in XML, people rose in protest. One justification is that this is the standard, and you are refusing to follow it. But I will try again to give you a more technical explanation. The use of systemId in the XML Catalog is expressly to model production [75], ExternalID, of the XML spec. I think it is good architecture to model what the catalog does on what the XML spec is doing. XML has no concept of a URI. It only has a concept of ExternalID with a SystemLiteral. Furthermore, XML's SystemLiteral cannot have a fragment ID: It is an error for a fragment identifier (beginning with a # character) to be part of a system identifier. So the datatype of the systemId entry is different from the datatype of the uri entry. Another reason it makes good architectural sense to have two different entry types. I see ZERO reason why the two following URI-Reference made from a single XML entity should lead to using different resource for http://example.com/foo.dtd: --- DOCTYPE foo SYSTEM http://example.com/foo.dtd foo xi:include href=http://example.com/foo.dtd; parse=text/ /foo --- In addition to my explanation above--and the fact that your example is not going to be a common one, so such redundancy is in fact going to be rare--there are other good reasons why these two URIs might want to be treated differently. Many XML processors provide an option to compile the external subset for certain optimized uses, so the system identifier (in the doctype line) might really resolve to some compiled form, but the URI in the xinclude element would want to resolve to the uncompiled form. Or I might know that my application ideally supports a slightly different version of the DTD, so I want to map the system id into some other file--maybe one on my local system, or maybe off to the latest test version of the DTD on sourceforge--but the version I want to include as text in my document should be the official current version of the DTD. paul
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
At 14:08 2002 10 30 -0500, Daniel Veillard wrote: On Wed, Oct 30, 2002 at 11:25:02AM -0600, Paul Grosso wrote: But I will try again to give you a more technical explanation. The use of systemId in the XML Catalog is expressly to model production [75], ExternalID, of the XML spec. I think it is good architecture to model what the catalog does on what the XML spec is doing. The XML spec in 4.2.2 explicitely state that in production 75 the System ID is an URI-Reference and link to RFC 2396. RFC 2396 ftp://ftp.ietf.org/rfc/rfc2396.txt defines: URI-reference = [ absoluteURI | relativeURI ] [ # fragment ] The XML spec says a system identifier cannot include a fragment identifier. So the XML system identifier matches [ absoluteURI | relativeURI ] in RFC 2396 (for which there is no single name given in 2396) whereas the URIs matched by the uri catalog entry match the full URI-reference production above. The XInclude spec does the same for the href attribute. There is no XML Base, so both references uses the same base and anybody with some common sense would expect the two references to get to the same resource. An XInclude href consists of a URI. An XML doctype declaration's ExternalID consists of both a public identifier and a system identifier. They sound very different to me, and it makes perfect sense for two such different references to be able to resolve to different resources. At 13:54 2002 10 30 -0500, Daniel Veillard wrote: On Wed, Oct 30, 2002 at 11:25:02AM -0600, Paul Grosso wrote: Many XML processors provide an option to compile the external subset for certain optimized uses, so the system identifier (in the doctype line) might really resolve to some compiled form, but the URI in the xinclude element would want to resolve to the uncompiled form. haha, that's the underlying implementation breakage which is the cause of all this !!! This means you have internal APIs which doesn't allow you do make the differentiation, this does not justify pushing that differentiation at the description level, sorry :-( I fail to see what is broken. I don't understand your point about internal APIs. Users want to be able to point to different resources in the case of system ids and URIs. Or I might know that my application ideally supports a slightly different version of the DTD, so I want to map the system id into some other file--maybe one on my local system, or maybe off to the latest test version of the DTD on sourceforge--but the version I want to include as text in my document should be the official current version of the DTD. Hum, and you expect this to not lead to huge confusion Absolutely not. It is a user requirement to be able to do this, and it is a reasonable architectural requirement to support. I have users telling me they want to do this, and it makes perfect sense to me what they want to be able to do. As a result all users for all XML tool chain using catalogs suddenly MUST duplicate ALL their SYSTEM entries into URI entries just to avoid this ? This is broken ! You don't have to duplicate all system entries because you don't need URI entries unless you want to point to a DTD (which is what system ids usually point to) as something other than a DTD which is a rare occurrence. I very much disagree with your broken assertion, Daniel. You asked for an explanation, and I gave it to you, and you respond by telling me my users' requirements are broken. And you think this justifies your insisting on keeping your implementation non-compliant with an OASIS specification! paul
Re: DOCBOOK-APPS: doublespacing and end-notes
At 23:58 2002 10 24 -0700, Bob Stayton wrote: I don't believe there is any support in DocBook XSL for end notes instead of footnotes. On the FO side, I don't think XSL-FO has direct support for end notes using the fo:footnote element. End notes would make a good feature request. I would argue that doing end notes is an XSLT thing, not an FO thing. paul
Re: DOCBOOK-APPS: Experiment for Notes on Graphics in HTML
Ed, Thanks for the interesting experiments. Just fyi, I use Netscape 4.7x, and all the graphics look the same size. (I also have IE6.0, and I did see the expected results with IE6.0.) I realize that Netscape 4.x has pretty pitiful support in this area. However, if one is trying to generate HTML that maximizes the number of real users out there that can properly view it, that may argue for pre-scaling. Maybe there is a way to maximize things in both directions. Perhaps (if one has the resources to do all this), what should be done is to pre-scale the graphics so that they will work on the maximum number of browsers, and then add the kind of CSS you're suggesting so that end users (with browsers that support this) can still have the control you want them to have. I'm not sure exactly how all this translates into what should the DocBook stylesheets do, but it does make for an interesting discussion on how to optimize automated web site generation via XSL. paul At 16:07 2002 05 05 -0400, you wrote: You may remember there was an exchange between Paul Grosso and I late last week on Norm's Notes on Graphics in HTML. To try to increase my own understanding of what I was trying to say, I've put together a very quick and dirty and, perhaps, superficial page with some illustrations of cascading styles and image handling. You can find it here: http://www.lynnparkplace.org/DBDiscuss/HTMLAndImages.html Perhaps it will be useful for others, as well. Note that this is not sourced in XML/DocBook and converted via XSL or DSSSL; I simply banged out some XHTML in Homesite by way of use cases to illustrate some options and opportunities. Any DB modifications or customizations would have to target these or similar features. I find I've gotten a bit polemical in the text; for that I apologize. It's not very long. The main purpose of the experiment is to assess the extent to which it's possible to leave the manipulation of image dimensions to the last minute, i.e. through rules in a CSS, perhaps a personal style sheet. Why one would want to do that is the reason for the polemic. In any event and irrespective of your feelings, I'd be grateful for comments or feedback, either to the list or personally, off line. In addition, if you have suggestions or questions or additions that you'd like me to try, let me know. It's all grist for the mill. Regards. ...edN
Re: DOCBOOK-APPS: Experiment for Notes on Graphics in HTML
At 12:51 2002 05 06 -0400, Ed Nixon wrote: Thanks. As I mention in the item, proper scaling is definitely the best thing to do for numerous reasons; whatever proper might mean to a visually disabled individual. Maybe the simplest thing to do, if this seems like an important issue, would be to provide a switch that turns off HTML source imbedded height and width attributes. However, I'm not being inundated with excited responses to this so perhaps it's a non starter; that would be unfortunate. Nonetheless, if that's the case, I'd be grateful for some input about how to develop a customization that does remove the imbedded dimensions. I'd copy the process.image template in the graphics.xsl into your customization file and fiddle it. You can see where Norm sets the height and width variables and then sets the img tag's attributes to their values. It's easy to comment out the lines that set the attributes if that's what you want to do. If you want to get fancier--like do something with your div idea--it'll take a bit more work (that I haven't analyzed). paul
Re: DOCBOOK-APPS: Notes on graphics and HTML
Norm and I discussed this some more off line and we clarified
several things for each other.
Some more comments embedded.
At 08:39 2002 05 03 -0400, Ed Nixon wrote:
Notes below:
At 02:44 PM 02/05/2002 -0500, Paul Grosso wrote:
At 12:41 2002 05 01 -0700, Norman Walsh wrote:
snip
1. If only the content-area is specified, everything is fine.
(If you ask for a three inch image, that's what you'll get.)
Yep (as long as the XSL-HTML stylesheets convert 3in to pixels, since
the value of an html::img.{width,height} attribute has to be a unitless
number of pixels).
I don't see how this could work given the variability of pixels/inch in screen
resolutions and settings. Can you explain?
The short answer is that, in general, pixels don't work. They are
terrible things to use when specifying style. However, the HTML
language and browsers don't give you much of a choice.
The rest of the answer is that, though CSS has an extended discussion
of pixels, the bottom line is most browsers use a default of something
close to 90-96 pixels per inch (as the CSS 2 spec suggests).
As you noticed below, the DocBook stylesheets have a parameter
$pixels.per.inch that defaults to 90, and this is how it works.
3. If both the content-area and the viewport-area is specified
on a graphic element, ignore the viewport-area.
(If you ask for a three inch image in a five inch area, we'll assume
it's better to give you a three inch image in an unspecified area
than a five inch image in a five inch area.
This is reasonable. I assume one could wrap the 3in image in a 5in block,
but I suspect what you suggest above is more likely to make the user happy.
Relative units also cause problems. As a general rule, the stylesheets
are operating too early and too loosely coupled with the rendering engine
to know things like the current font size or the actual dimensions of
an image. Therefore:
1. We use a fixed size for pixels, $pixels.per.inch
2. We use a fixed size for ems, $points.per.em
Ok, that answers my question above but how portable is this solution across platforms
and workstation configurations, e.g. for people who, of visual necessity, run their
machines a low res.
About as portable as HTML. This is how browsers work.
Sometime it gives lousy results, but usually no one
seems to notice much.
Or just say that it is an error for docbook::graphics.{width,depth} to be
assigned a value whose unit is em.
If I understand this correctly, aren't you taking away my ability to create HTML
output that conforms with WAI and 508 guidelines? Via CSS?
I don't understand how saying we shouldn't use em does this.
Can you explain?
Percentages are problematic. In the following discussion, we speak
of width and contentwidth, but the same issues apply to depth and
contentdepth
1. A width of 50% means half of the available space for the image.
That's fine. But note that in HTML, this is a dynamic property and
the image size will vary if the browser window is resized.
2. A contentwidth of 50% means half of the actual image width. But
the stylesheets have no way to assess the image's actual size. Treating
this as a width of 50% is one possibility, but it produces behavior
(dynamic scaling) that seems entirely out of character with the
meaning.
Worse, mapping docbook::graphics.width=200% to html::img.width=200%
guarantees that the graphic will be twice as large as the window which
is almost never what the user wants to see.
Instead, the stylesheets define a $nominal.image.width.in.points
and convert percentages to actual values based on that nominal size.
While I can't see a good solution, I also can't imagine this working too well
either. What kind of value do you choose for $nominal.image.width.in.points
that works more often than it doesn't?
The answer to my own question is that this doesn't work too well,
but there is no better solution (short of an extension that allows
the stylesheet to get the content's implicit dimensions).
Again, same objection as the last one.
Which is what? (Sorry, I'm not trying to be dense. Must be
too early still for me.)
Perhaps you're trying to over specify these measures in order to accommodate XSL
processing issues which, in tern, are an over specification of the HTML output. Why
not leave the Image attributes in HTML for final and dynamic sizing to an external
CSS? With a CLASS or ID attribute selector? Surely the admin and upkeep overhead are
similar to that of tweaking parameters in the XSL kit and better located in the
processing flow. And maybe better understood or learn.
I don't understand what you are suggesting here.
What do you mean leave the Image attributes in HTML?
The only attributes on the IMG tag are width and height
and their values must
Re: DOCBOOK-APPS: Notes on graphics and HTML
At 11:15 2002 05 03 -0400, Ed Nixon wrote:
At 08:47 AM 03/05/2002 -0500, Paul Grosso wrote:
The short answer is that, in general, pixels don't work. They are
terrible things to use when specifying style. However, the HTML
language and browsers don't give you much of a choice.
Don't understand this assertion, I'm afraid, unless you are referring solely to
images. And I think the cut/paste below contradicts this assertion.
I've answered below.
Or just say that it is an error for docbook::graphics.{width,depth} to be
assigned a value whose unit is em.
If I understand this correctly, aren't you taking away my ability to create HTML
output that conforms with WAI and 508 guidelines? Via CSS?
I don't understand how saying we shouldn't use em does this.
Can you explain?
My interpretation of what is being suggested is that the image attributes you set via
XML -- XSL -- HTML processing will be imbedded as attribute values in the HTML
source code output;
Yes. If the DocBook source gives sizing attributes, they
will/should be passed through to the HTML, I would think.
if I'm not mistaken these values will override any values I may choose to establish
in my customized external CSS; if that is the case then you are taking away my
ability and that of the end user to customize at view time in favour of customizing
at, say, serve time.
Then you shouldn't have put those values into the DocBook source.
The stylesheets aren't trying to take anything away from you, they
are just translating the DocBook input into HTML output. If you
have a different plan for how images should be scaled, then I assume
your DocBook input wouldn't have any sizing attributes.
Further, I'm not convinced customizing at serve time is necessary when it can be
done (in many cases) adequately and more simply/flexibly at view time, i.e. with CSS
and/or alternative CSS files.
I don't know how to scale images via CSS in such a way as to
provide much greater end-user flexibility than you can get
with straight HTML. In any case, as I've said above, if you
put size info on the DocBook source, the stylesheets have to
assume you meant it and want it so they translate that, as
best they can, to the HTML.
Perhaps you're trying to over specify these measures in order to accommodate XSL
processing issues which, in tern, are an over specification of the HTML output. Why
not leave the Image attributes in HTML for final and dynamic sizing to an external
CSS? With a CLASS or ID attribute selector? Surely the admin and upkeep overhead are
similar to that of tweaking parameters in the XSL kit and better located in the
processing flow. And maybe better understood or learn.
I don't understand what you are suggesting here.
What do you mean leave the Image attributes in HTML?
The only attributes on the IMG tag are width and height
and their values must be a unitless number of pixels.
I've pasted in a section from the HTML 4.01 specification (sorry for the formatting.)
Things may have changed in subsequent versions of HTML but I don't have them handy.
It seems to indicate that, at minimum, percentages may be specified and length units.
In addition, there are other attributes associated with IMG: style, vspace, hspace,
align, etc. All, in one way or another, potentially inter-related to the discussion.
Here's the clip:
//***
height = length [CN]
Image and object height override.
When specified, the width and height attributes tell user agents to override the
natural image or object size in favor of these values.
When the object is an image, it is scaled. User agents should do their best to scale
an object or image to match the width and height specified by the author. Note that
lengths expressed as percentages are based on the horizontal or vertical space
currently available, not on the natural size of the image, object, or applet.
The height and width attributes give user agents an idea of the size of an image or
object so that they may reserve space for it and continue rendering the document
while waiting for the image data.
**//
vspace, hspace, and align have nothing to do with image sizing.
Only html::img.{width,height} have anything *directly* to do
with image sizing. Note that the spec says %Length; is nn
for pixels or nn% for percentage length (that quote comes
straight from the DTD).
So the only capability beyond given a dimension in pixels is
the nn% which, as you note, is a percent of the available width.
This is precisely what Norm and I were discussing in an earlier
message where we exhanged:
-
Percentages are problematic. In the following discussion, we speak
of width and contentwidth, but the same issues apply to depth and
contentdepth
1. A width of 50% means half of the available space for the image.
That's fine. But note that in HTML, this is a dynamic property and
the image size will vary if the browser window is resized.
2. A contentwidth
Re: DOCBOOK-APPS: Notes on graphics and HTML
At 12:41 2002 05 01 -0700, Norman Walsh wrote:
I spent some time today working on new code to map DocBook V4.2 image
semantics (a superset of previous semantics) to HTML. A number of
compromises were required along the way.
I probably won't be able to post the new code until I get back home,
but here are the notes I wrote as I went. Comments, etc., most welcome.
I find use of the terms like width are ambiguous. I've gotten into
writing things like docbook::graphic.width and html::img.width.
!-- The HTML img element only supports the notion of content-area
scaling; it doesn't support the distinction between a content-area and
a viewport-area, so we have to make some compromises.
Pretty much true, but note that html::img.{width,height}=xx% implies
that the graphic should be scaled to xx% of the available width
(aka of the viewport-area).
One thing I'm confused about is whether docbook allows values of the
form xx% for docbook::graphics.{width,depth} and
docbook::graphics.content-{width,depth} and, if so, what they all mean?
Unless I hear otherwise, I'll assume that docbook::graphics.{width,depth}
values can only be lengths with units being one of the following and
nothing else: cm, mm, in, pt, pc, px.
1. If only the content-area is specified, everything is fine.
(If you ask for a three inch image, that's what you'll get.)
Yep (as long as the XSL-HTML stylesheets convert 3in to pixels, since
the value of an html::img.{width,height} attribute has to be a unitless
number of pixels).
2. If only the viewport-area is provided:
- If scalefit=1, treat it as both the content-area and
the viewport-area. (If you ask for an image in a five inch
area scaled to fit, we'll make the image five inches to fill
that area.)
- If scalefit=0, ignore it.
Note: this is not quite the right semantic and has the additional
problem that it can result in anamorphic scaling,
Why should this have to result in anamorphic scaling? Can't we define the
semantic so that anamorphic scaling doesn't occur?
which scalefit
should never cause.
True.
3. If both the content-area and the viewport-area is specified
on a graphic element, ignore the viewport-area.
(If you ask for a three inch image in a five inch area, we'll assume
it's better to give you a three inch image in an unspecified area
than a five inch image in a five inch area.
This is reasonable. I assume one could wrap the 3in image in a 5in block,
but I suspect what you suggest above is more likely to make the user happy.
Relative units also cause problems. As a general rule, the stylesheets
are operating too early and too loosely coupled with the rendering engine
to know things like the current font size or the actual dimensions of
an image. Therefore:
1. We use a fixed size for pixels, $pixels.per.inch
2. We use a fixed size for ems, $points.per.em
Or just say that it is an error for docbook::graphics.{width,depth} to be
assigned a value whose unit is em.
Percentages are problematic. In the following discussion, we speak
of width and contentwidth, but the same issues apply to depth and
contentdepth
1. A width of 50% means half of the available space for the image.
That's fine. But note that in HTML, this is a dynamic property and
the image size will vary if the browser window is resized.
2. A contentwidth of 50% means half of the actual image width. But
the stylesheets have no way to assess the image's actual size. Treating
this as a width of 50% is one possibility, but it produces behavior
(dynamic scaling) that seems entirely out of character with the
meaning.
Worse, mapping docbook::graphics.width=200% to html::img.width=200%
guarantees that the graphic will be twice as large as the window which
is almost never what the user wants to see.
Instead, the stylesheets define a $nominal.image.width.in.points
and convert percentages to actual values based on that nominal size.
While I can't see a good solution, I also can't imagine this working too well
either. What kind of value do you choose for $nominal.image.width.in.points
that works more often than it doesn't?
Scale can be problematic. Scale applies to the contentwidth, so
a scale of 50 when a contentwidth is not specified is analagous to a
width of 50%.
This is confused/confusing. You are talking about contentwidth and width
in the same sentence without making it clear if you are talking about
docbook::graphic.content-width or docbook::graphic.width or html::img.width.
I think you're talking about docbook::graphics.scale=50. I think you're
saying that this is equivalent to docbook::graphics.content-width=50%. (It
sure isn't equivalent to
Re: DOCBOOK-APPS: Processing Instructions and structure
At 14:31 2002 03 25 -0800, Bob Stayton wrote: I'm branching the subject here, hence the new Subject line. On Mon, Mar 25, 2002 at 04:34:52PM -0500, Norman Walsh wrote: 1. Directory levels are cumulative. Given: book ?book filename=b.html? chapter ?dbhtml dir=chap1 filename=c.html? section ?dbhtml dir=sect1 filename=s.html? ... b.html will go in the current directory c.html will go in chap1/ s.html will go in chap1/sect1/ 2. You must not use absolute path names. 3. You must not use ../ in any path name. This scheme looks fine, but for me it raises a long-standing question I have about whether or how processing instructions fit into a document's structure. The XML Recommendation doesn't say anything out it. There's nothing to say. PIs are nodes in the tree with no (non-character) substructure. There is nothing to be said about how PIs work; by their very definition, how processing instructions are interpreted is defined by the processor planning to process them (or the person defining them in the first place). If you look at your example: chapter ?dbhtml dir=chap1 filename=c.html? section ?dbhtml dir=sect1 filename=s.html? You have associated the PI dir=chap1 with chapter by putting it inside the chapter element. So the rule is that a PI applies to the element that contains it, I guess. The rule is whatever Norm says it is, since he (and, implicitly, the stylesheets he has written that deal with these PIs) is defining the processing expectation for these processing instructions. So he'll have to answer some of your detailed questions (or you could read the stylesheets and perhaps find out that way). Are the rules of PIs always set by the application (in this case, how the stylesheet interprets them)? Yes. paul
Re: DOCBOOK-APPS: creating Japanese output from DocBook sources
At 12:12 2002 03 12 -0500, Nancy (Paisner) Harrison wrote: We're using DocBook for our English documentation, but will have to localize it for the Japanese market. We're using Epic for our print material, but Epic doesn't support creation of print in Japanese (they say it will be in a 'future release' but it's not something I can bank on). So, I'm interested in finding out what tools folks are using with DocBook to generate Japanese printed and HTML output. Our customers are on both UNIX and Windows, so we need both EUC and SJIS. Hi Nancy, Here is the official word from our product marketing folks: The current release of Epic Editor (4.2.1) supports CJK *editing*. The next significant release of Epic (4.3), which we will announce at AUGI (our annual Users Group meeting in Montreal May 14-17) and expect to deliver in June, will support CJK *printing*. In the meantime, Adept 8.1 is the latest release that supports CJK printing. regards (and salutations from way back), paul
Re: DOCBOOK-APPS: long strings
One should also be able to insert shy; (which is defined in the character entity files that are part of the DocBook DTD--or you can just use #173;) to insert a discretionary hyphen. This will cause a hyphen (dash) character to be printed at the end of the line if a break is taken here. One can also insert #8203; which is the zero width space character which allows a line break here without the insertion of a dash. (This character may not be implemented as such in all formatters.) In both cases, if the line isn't broken at that spot, your output doesn't have an introduced space as would be the case with solution 1. paul At 09:48 2002 03 07 +0100, Camille Bégnis wrote: Hi Tim, Three solutions: 1) The quick and dirty: Add a space/newline where you want the line to be cutted 2) The tedious and clean: put the long string into another tag like parameter and make sure it is processed with the \url TeX command and package. 3) The tricky: reduce the font size for userinput ;-) Camille. Tim Terlegård a écrit : If I have a very long string it won't be broken down to two or more lines, the last part just dissapears outside the paper (or pdf). I have this: userinput$ snmpwalk hostname communitystring host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstallName/userinput The last part in the last string will be cut out from the document. How should I solve this? I thought of SBR, but it doesn't seem to be available in para or userinput. I'm using DSSSL 1.72 Thanks, Tim
Re: DOCBOOK-APPS: Using DocBook XSL for previewing in XMetaL 3.0?
At 08:57 2002 02 28 +0100, Kraa de Simon wrote: I like the way I can do XSL transformations from within XML Spy directly (by 'assigning a XSL file to the XML document) So the authors can 'preview' the document from within the XML editor by just pushing a button (without any knowledge of the transformation process) I don't think this was possible in XMetaL 21 (correct me if I'm wrong) I don't know any specifics about either XML Spy or XMetal, but the way to assign an XSL file to the XML document is via the xml-stylesheet PI; see http://3org/TR/xml-stylesheet/ Assuming this were properly implemented, would this address your need? paul
Re: DOCBOOK-APPS: Customizing PDF look and feel using DocBook,Epic Print Composer and XSL-FO
I just subscribed to this list, so pardon the late response (and the fact that this will probably not be properly linked in the archive). I'll try to inject some info into the discussion, but if things get into too many Epic-specific details, we should probably take it offline (I'm not yet sure how much this list tolerates product-specific discussion, so just let me know if I get out of line). Date: Tue, 22 Jan 2002 10:11:21 -0800 From: Tristan Bishop [EMAIL PROTECTED] Subject: DOCBOOK-APPS: Customizing PDF look and feel using DocBook, Epic Print Composer and XSL-FO To: [EMAIL PROTECTED] I'm on Windows 2000. I'm using the DocBook XML DTD, more accurately, the Arbortext ATI XML DocBook V4.0 DTD. This is the DTD that works with the Arbortext Epic Print Composer product. For styling, I'm using the DocBook 1.48 style sheets that I downloaded from Source Forge. Distributed with Epic 4.2 are the 1.40 version style sheets, and if you use the axdocbook samplefo.xsl driver file, it includes various improvements and bug fixes to the 1.40 distribution. We plan to update our stylesheets with newer ones from Source Forge in a mid-year release. Meanwhile, if you want to use a different version, that should work too. I'm also using the Arbortext Epic 4.2 editor, and their Print Composer engine. As far as I know, the Arbortext engine contains Xalan for XSL processing, Correct, internally we use Xalan. as well as some kind of converter (possibly FOP?) to go from FO's to post script. I'm then using Adobe Acrobat distiller 5.0 for Windows to go from PS to PDF. We do not use FOP, we have our own FO implementation that feeds into our TeX-based formatting engine. Our XSL FO composition support is being improved constantly, and there are patches available to apply the fixes to Epic 4.2 or 4.2.1. Contact me if you want the patch (it'll be a 92KB zip file I can email you). (Though I am using the Arbortext DTD, I'm not using any Arbortext extensions, nor did I enable these extensions via the Arbortext extensions parameter in the DocBook FO style sheets.) There are no Arbortext extensions at this time, and the Arbortext extension parameter in the DocBook FO style sheets doesn't really do anything related to the XSL FO composition. CONVERSION: I was able to successfully generate PDF content using the default source forge style sheets. So, to move forward, I then created a customization layer, using instructions found at the following websites: http://www.dpawson.co.uk/docbook/styling/custom.html http://www.nwalsh.com/docs/articles/dbdesign/#parameterization As instructed, I placed my custom.xsl file in the FO directory, and used an import statement to trigger docbook.xsl. See below: xsl:import href=docbook.xsl/ That said, I now have two primary, and prohibitive issues: ISSUE NUMBER 1) Not all parameters respond to my customization layer. I used the FO parameter Reference list found at: http://docbook.sourceforge.net/projects/xsl/doc/fo/ Many of the customized parameters work just fine. Such as: xsl:param name=admon.graphics select=1/ xsl:param name=body.font.familyArial/xsl:param xsl:param name=title.margin.left select='0pc'/ Other recommended customization parameters simply do not change the resulting PDF output. Examples of ignored parameters include: page.margin.bottom page.margin.inner page.margin.outer page.margin.top Page margins were not supported in Epic 4.2. If the above mentioned patch is applied, they should work. (Note, the Epic 4.2 release had its XSL FO code frozen last August, so there has been a fair amount of work on it since then. This patch to which I am referring will be reflected in the Epic 4.2.3 release due to come out in April.) ISSUE NUMBER 2) The file path to reference graphics is being mangled Within my DocBook XML source, I use the graphic element to refer to screen shots. The syntax is: graphic fileref=abcdefg.jpg/ When I run the conversion, I receive an error message stating: [A12630] Error: The graphics file cdefg.jpg could not be opened. No matter what the file name or file path, the conversion process cuts of the first two letters of the file name. So if my graphic is /12345/abcdefg.jpg The error will say: [A12630] Error: The graphics file 345/abcdefg.jpg could not be opened. I don't know for sure about this without more details, but graphics should work in the axdocbook sample using our stylesheets. Perhaps you can try formatting our axdocbook sample with our distributed stylesheets to make sure that is working. If that works but your customized stylesheets don't, then I'd have to have more details (probably best done offline). (BTW, my admonishment graphics (called by the style sheets) show up just fine in the PDF output, but not the screen shots.) === My questions: Why are some parameters ignored? The XSL FO patch is needed. Email me offline for this. What's going on with the graphic element? I don't know, but if the problem persists
