[docbook-apps] EPUB parameters: (epub.cover.id)
Hi, I'm a docbook newbie who has been testing the latest 1.7.5.1 epub transform in Oxygen. I'm having trouble figuring out the meaning of the epub parameters, especially the ones related to cover. (see bottom) I know that docbook has a cover element, but cover in the context of epub parameters seems to mean something different. (Or am I supposed to assume that the cover image information should be inside a mediaobject element which is inside docbook's cover element?) Does epub.cover.filename assume that the file is an html file or a graphic file? Will the epub.cover.image.id refer to a file name or simply be an identifying attribute? Finally, I see this note on docbook.xsl !-- Via Martin Goerner: On covers: the IDPF2.0 standard unfortunately does not have a provision for covers. We had to add one and we did so in conjunction with the IDPF and various publishers. The tag chosen to define the covers is: meta name=cover content=-reference to a manifest item- Then, we also added a bit of logic to get rid cleanly of the HTML cover people usually add because the logical cover is not specced by the IDPF. So, if the HTML cover item is marked linear=no AND there is a guide item of type=cover pointing to it AND there is a logical cover specified in a meta name=cover tag, THEN, the HTML cover is discarded. -- I'm sorry; I don't understand exactly what this means. Does he mean that in the html output from docbook you include cover information in a meta tag ? Is there a file reference inside this meta tag? Also, when epub.cover.linear = 0 or 1, what does that mean? It would be nice to see a simple example of the values used to produce a cover. Thanks for your help. Robert xsl:param name=epub.autolabel select='1'/ xsl:param name=manifest.in.base.dir select='1'/ xsl:param name=base.dir select=$epub.oebps.dir/ xsl:param name=epub.oebps.dir select='OEBPS/'/ xsl:param name=epub.ncx.filename select='toc.ncx'/ xsl:param name=epub.container.filename select='container.xml'/ xsl:param name=epub.opf.filename select=concat($epub.oebps.dir, 'content.opf')/ xsl:param name=epub.cover.filename select=concat($epub.oebps.dir, 'cover', $html.ext)/ xsl:param name=epub.cover.id select='cover'/ xsl:param name=epub.cover.image.id select='cover-image'/ xsl:param name=epub.cover.linear select=0 / xsl:param name=epub.ncx.toc.idncxtoc/xsl:param xsl:param name=epub.html.toc.idhtmltoc/xsl:param xsl:param name=epub.metainf.dir select='META-INF/'/ xsl:param name=epub.embedded.font/xsl:param -- Robert Nagle 12777 Ashford Point Dr #1417 Houston, Texas 77082 713 893 3424 htpt://www.robertnagle.info - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] EPUB parameters: (epub.cover.id)
On Tue, Jun 23, 2009 at 2:32 PM, Robert Nagleidiotprogram...@gmail.com wrote: I'm having trouble figuring out the meaning of the epub parameters, especially the ones related to cover. (see bottom) The cover can be a little bit tricky to generate generically in DocBook 4.x because of the lack of the cover element. It should be simpler in DocBook 5.0. I know that docbook has a cover element, but cover in the context of epub parameters seems to mean something different. (Or am I supposed to assume that the cover image information should be inside a mediaobject element which is inside docbook's cover element?) Does epub.cover.filename assume that the file is an html file or a graphic file? In general, most of the epub.* parameters should be left as the default unless you're writing an EPUB generation tool. The epub.cover.filename contains the name of the generated cover XHTML file. Will the epub.cover.image.id refer to a file name or simply be an identifying attribute? The epub.cover.image.id is used to identify the cover in the OPF file. Finally, I see this note on docbook.xsl !-- Via Martin Goerner: On covers: the IDPF2.0 standard ... I'm sorry; I don't understand exactly what this means. Does he mean that in the html output from docbook you include cover information in a meta tag ? Is there a file reference inside this meta tag? You shouldn't need to worry about this. Also, when epub.cover.linear = 0 or 1, what does that mean? One typically keeps the cover out of the OPF spine. The default of 0 keeps it out. It would be nice to see a simple example of the values used to produce a cover. You can see an example of a DocBook 4.x cover here (less clearly): https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/epub/bin/spec/files/orm.book.001.xml and 5.0 here (more clearly): https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/epub/bin/spec/files/v5cover.xml Keith - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] OK, still can't get a working redaction
I'm still trying to figure out a mechanism for redacting elements in DocBook markup. Basically, I would like to do something to handle redaction via attribute manipulation, such that the following sentence ... Hi, I'm personname redact=truefirstnameDavid/ firstnamelastnameNedrow/lastname/personname. ... renders as ... Hi, I'm . Or the variant ... Hi, I'm personnamefirstname redact=trueDavid/firstname lastname redact=trueNedrow/lastname/personname. ... which renders as ... Hi, I'm X XX. ... where the Xs would render as a solid black field the size of the redacted element. Eg., a redacted image would be rendered as a black area equal to the dimensions of the image element that would have been rendered. I think my confusion primarily is caused by not being clear on where this would actually happen. I want to keep the actual markup as simple as possible, and handle all the processing in my customization layer. So, should I somehow create a new attribute as shown above, or a new inline similar to the 'cleartext' example in DocBook 5 Guide. An attribute that applies to certain (or possibly all?) elements would be better in my mind. The second part of this is, where do I make the magic happen after an element to be redacted has been parsed? Would this actually be handled by the XSL stylesheets, or the rendering engine (XEP in my case)? Or a combination of both. Is this actually a question for RenderX (XEP vendor)? -David Nedrow - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] OK, still can't get a working redaction
David E Nedrow wrote: I'm still trying to figure out a mechanism for redacting elements in DocBook markup. That depends on your delivery mechanism. You can render text in PDF or HTML in black-on-black, and it will *look* right, but the text will still be there for people to copy and paste, search for, etc. If you are delivering dead trees printed with the PDF, then the information should be relatively safe. This would be relatively easy to implement; a small change to the CSS for HTML, and a fairly straightforward implementation of the redact attribute in the FO stylesheets. You could also try printing a series of non-breaking spaces or Xs in black-on-black, equal in length to the characters in the elements in question; the stylesheet customization would be a bit more complicated for that solution. (La plus ça change... I remember a certain government agency asking for this feature in DynaText in 1995 or so...) ~Chris -- Chris Maden, text nerd URL: http://crism.maden.org/ “All I ask of living is to have no chains on me, And all I ask of dying is to go naturally.” — Laura Nyro GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319 - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
