Re: [docbook] LaTeX math inside docbook, on-the-fly MathML conversion?
Alexey Neyman sti...@att.net wrote on Thu, 29 Jan 2015 12:34:05 -0800: I found this quite useful for PDF output: http://pmml2svg.sourceforge.net/ This XSL stylesheet converts MathML to SVG. SVG can be then inserted into the XSL-FO for PDF output or converted to PNG for HTML. I'm the person behind pmml2svg. I think its output is clearly superior to JEuclid in most cases, mostly because JEclid literally handles stretchy characters by anisotropic scaling of glyphs. Yet I sadly do not eat my own dog food most of the time. The reason is that pmml2svg relies on FOP code handle font metrics, and FOP is currently limited to Unicode plane-0 code points (https://issues.apache.org/jira/browse/FOP-1969), but I often use Mathematical Alphanumeric Symbols (1D400–1D7FF). Since my use case for pmml2svg relies on FOP for PDF output, I have had little motivation to remove pmml2svg's dependency on FOP. Moreover, while I think MathML-to-SVG conversion coded entirely in XSLT is cool and fits well into XML workflows, math rendering is not trivial, and MathML keeps evolving, so implementation and maintenance cannot be done without community help. Perhaps it would be better to try to write a MathML-to-SVG converter and/or a FOP math plugin based on an established math rendering system such as Gecko or MathJax. If you want to use inline formulas, you'd need a small hack to pass the baseline shift generated by pMML2SVG (which is stored in the generated SVG) into the XSL-FO attribute. I have a patch for that somewhere; I'll dig it up if you're interested. I am :-) For LaTeX-to-MathML conversion I use TTM (http://hutchinson.belmont.ma.us/tth/mml/). In the meantime many other converters have appeared (that I have never felt the pressure to try out). Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook] DocBook Technical Committee Meeting Minutes: 15 August 2012
Are these Gabor Kovesdan's slides, or something else? Justus Bob Stayton b...@sagehill.net wrote on Wed, 15 Aug 2012 11:06:53 -0700: 8. Add slides schema variant to DocBook 5? We discussed how to handle schema extensions at a previous meeting. ACTION: Bob to research what we decided before. Larry suggested that perhaps the slides extensions could be implemented in DocBook assembly, with outputformat=slides. Dick thought the DocBook website schema might fit into that as well. ACTION: Bob to send the proposed slides schema to the TC. ACTION: Larry to try mapping slides to assembly. - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
[docbook] Re: [docbook-apps] Re: [docbook] DocBook Slides 5.0 beta1 available for testing
Gabor Kovesdan ga...@kovesdan.org wrote on Sat, 18 Aug 2012 19:18:49 +0200: - Multiple mediaobject children appear all to be rendered, although only one of them should be. How can this happen? I would think that this is handeled by the stock DB stylesheets, not by anything specific to Slides. (I see this in informalequation/mediaobject, where I have textobjects containing LaTeX and auto-generated MathML, respectively.) I think I modified the template for this. If only one should be rendered why does the schema allow more? DB Slides uses this possibility to allow more imageobject's inside. This violates the spec; see The Definitive Guide (http://www.docbook.org/tdg51/en/html/mediaobject.html): The primary purpose of the mediaobject is to provide a wrapper around a set of alternative presentations of the same information. - On my wishlist: speakernotes are currently only possible in specific places within slides, foilgroup and foil (as they were in DB5 I think). However, I see no reason to impose such restrictions. Why not allow attaching speakernotes to just about anything? ... ... But I have no strong opinion on this so if you prefer scatter your notes among real content elements, I don't object to such change. I'll add this to my todo list. I'll also have to modify the stylesheets so that you customize it. Great, thanks! This is important to me because I use speakernotes for material that I do not show on the slides but develop on the board and/or in dialog with students (which, I think, is well within the semantics of speaker notes). Anywhere speakernotes allow me to place the content exactly where it belongs. I also produce booklet output from the slides for the students that do include the speakernotes; thus, it is very important that the content appear in the right place. Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
[docbook] Re: [docbook-apps] Re: [docbook] DocBook Slides 5.0 beta1 available for testing
Gabor Kovesdan ga...@kovesdan.org wrote on Sat, 18 Aug 2012 20:18:54 +0200: Em 18-08-2012 20:13, justus-b...@piater.name escreveu: This is important to me because I use speakernotes for material that I do not show on the slides but develop on the board and/or in dialog with students (which, I think, is well within the semantics of speaker notes). Anywhere speakernotes allow me to place the content exactly where it belongs. I also produce booklet output from the slides for the students that do include the speakernotes; thus, it is very important that the content appear in the right place. Isn't handoutnotes more appropriate for that? Currently, it is defined like speakernotes but the semantical meaning is different. I'll modify the schema to allow both scattered. Sounds perfect to me! Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook-apps] Re: [docbook] DocBook Slides 5.0 beta1 available for testing
Gabor Kovesdan ga...@kovesdan.org wrote on Sat, 18 Aug 2012 19:18:49 +0200: - Multiple mediaobject children appear all to be rendered, although only one of them should be. How can this happen? I would think that this is handeled by the stock DB stylesheets, not by anything specific to Slides. (I see this in informalequation/mediaobject, where I have textobjects containing LaTeX and auto-generated MathML, respectively.) I think I modified the template for this. If only one should be rendered why does the schema allow more? DB Slides uses this possibility to allow more imageobject's inside. This violates the spec; see The Definitive Guide (http://www.docbook.org/tdg51/en/html/mediaobject.html): The primary purpose of the mediaobject is to provide a wrapper around a set of alternative presentations of the same information. - On my wishlist: speakernotes are currently only possible in specific places within slides, foilgroup and foil (as they were in DB5 I think). However, I see no reason to impose such restrictions. Why not allow attaching speakernotes to just about anything? ... ... But I have no strong opinion on this so if you prefer scatter your notes among real content elements, I don't object to such change. I'll add this to my todo list. I'll also have to modify the stylesheets so that you customize it. Great, thanks! This is important to me because I use speakernotes for material that I do not show on the slides but develop on the board and/or in dialog with students (which, I think, is well within the semantics of speaker notes). Anywhere speakernotes allow me to place the content exactly where it belongs. I also produce booklet output from the slides for the students that do include the speakernotes; thus, it is very important that the content appear in the right place. Justus - 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] Re: [docbook] DocBook Slides 5.0 beta1 available for testing
Gabor Kovesdan ga...@kovesdan.org wrote on Sat, 18 Aug 2012 20:18:54 +0200: Em 18-08-2012 20:13, justus-b...@piater.name escreveu: This is important to me because I use speakernotes for material that I do not show on the slides but develop on the board and/or in dialog with students (which, I think, is well within the semantics of speaker notes). Anywhere speakernotes allow me to place the content exactly where it belongs. I also produce booklet output from the slides for the students that do include the speakernotes; thus, it is very important that the content appear in the right place. Isn't handoutnotes more appropriate for that? Currently, it is defined like speakernotes but the semantical meaning is different. I'll modify the schema to allow both scattered. Sounds perfect to me! Justus - 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] Re: [docbook] DocBook Slides 5.0 beta1 available for testing
Hi Gabor, I have not been able to took a deeper look, and won't be for another few weeks, but I aim to use it in production from the end of September onwards. So, after a quick look at the Slidy transformation: - Fantastic! This is looking very promising. - dbs3-upgrade.xsl contains a typo: xsl:template name=slidesinfo|foilgroupinfo|foilinfo should probably read xsl:template match=slidesinfo|foilgroupinfo|foilinfo - dbs3-upgrade.xsl does not conserve attributes (such as id, which should incidentally be translated to xml:id) on dbs-namespaced elements, due to limitations in the process.content named template. - The generated HTML is invalid (at least with respect to the XHTML schema I use) due to various empty attribute values (xml:lang, lang, xmlns, class). - Multiple mediaobject children appear all to be rendered, although only one of them should be. How can this happen? I would think that this is handeled by the stock DB stylesheets, not by anything specific to Slides. (I see this in informalequation/mediaobject, where I have textobjects containing LaTeX and auto-generated MathML, respectively.) - On my wishlist: speakernotes are currently only possible in specific places within slides, foilgroup and foil (as they were in DB5 I think). However, I see no reason to impose such restrictions. Why not allow attaching speakernotes to just about anything? Here is what I have done for ages, and what I would like the stock DB Slides to adopt: local.divcomponent.mix = speakernotes local.component.mix= speakernotes local.example.mix = speakernotes (The use of local.* is of course my personal customization hack; this just to indicate where I think speakernotes should be allowed, at least.) I then render speakernotes into my personal view of the slides (see https://iis.uibk.ac.at/public/piater/talks/speaker/speaker.xhtml, which I plan to adapt to the new Slidy output). - Also on my wishlist: Target HTML5 output. I'd like my movies to be rendered by video elements, without my having to fiddle with stylesheets :-) - There are various sizing and spacing problems involving SVG graphics, but I do not have the time right now to investigate whether they are caused by your transformations or by weirdnesses in my own XML coding. Great work, keep it up! Justus - 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] Fwd: RE: [xep-support] ANNOUNCEMENT - RenderX moves to the Cloud
You may also want to take a look at my backburner project http://pmml2svg.sourceforge.net/. I'd rate its output pretty good (with teenage-TeX-trained eyes :-)). Contrary to JEuclid (among others), pmml2svg composes stretchy characters from component glyphs instead of stretching individual glyphs. The workflow is similar to SVGMath. I am still dreaming of including it into my own workflow (at which point it should move from backburner to afterburner :-)), but for now I fear it is less well maintained than SVGMath. Justus Jirka Kosek ji...@kosek.cz wrote on Mon, 25 Jun 2012 17:12:59 +0200: On 24.6.2012 19:54, Stefan Seefeld wrote: OK, thanks for the info. I'm happy to adjust the build rules to get this working. So far I couldn't find any instructions on how this is done, though. Do I need to process the original .fo file to substitute the MathML by SVG, before I pass it along to the FO processor ? Yes, exactly. Also, sometimes additional adjustment in FO are necessary, there is XSLT provided in SVGMath distribution for it. Basically you will need workflow similar to: saxon -o x.fo doc.xml fo.xsl python c:\SVGMath-0.3.3\math2svg.py -c c:\SVGMath-0.3.3\svgmath.xml -o y.fo x.fo saxon -o z.fo y.fo c:\SVGMath-0.3.3\fo\adjustbase.xsl xep -quiet -fo z.fo -pdf doc.pdf Also, what are the issues that makes the MML-SVG-PDF only acceptable, as opposed to good ? Does this affect all equations, or just specific expressions ? Well, if one gets used to TeX in teenage then it is very hard to give good rank to any other math typesetting system. :-) Jirka - 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] DocBook Slides 5.0 alpha1 available for testing
Hi Gabor, Gabor Kovesdan ga...@kovesdan.org wrote on Sat, 23 Jun 2012 08:21:14 +0200: I have no idea how to calculate what will fit on a slide and what won't and it also depends on the output format. I think this is beyond the scope of DB-Slides. It is up to the user to decide what to put on a slide. In HTML, the content can be scaled to fit using JavaScript (at least optionally), or the presenter can scroll (which often makes sense too). In FO, making a slide a page-sequence will automatically split the content across slides (but perhaps there is a way to auto-scale-to-fit the content as well). I suspect that consistent content positioning (without using tables) between HTML and FO targets will require some thought. To this end, will slide-specific markup be part of your project? I imagine you mean that you want to present the content on web and provide a printable version with the very same outlook No, I don't need strict consistency. But it would be nice to be able to use any suitable output formats for presentations (HTML, PDF, ...). It is easy (but cumbersome and abusive) to achieve almost any page layout using tables in a target-agnostic way. But if we want to layout HTML using CSS (float style, etc.), then we need DB Slides markup that is translated into CSS classes for HTML and into, say, tables for FO output. We have already discussed such markup on this list. I think incremental and collapsible should be properties of lists, ... And even if you include several lists, really would you want to make such a strange design that you make one of them incremental and not the rest? I think it would look strange and it is definitely not a really common use case so I thought it would be better to setup the incremental property on a per slide basis, which also spares messing with DocBook elements. Yes, I basically agree. (rantBesides, I almost never use incremental bullet points. They obscure context and rob the listener of the ability to anticipate where the speaker is headed. Most speakers using them end up microstepping through the bullet points, further damaging the thread of the presentation. Slides should support the speech, not vice versa./rant) Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
[docbook] Re: [docbook-apps] DocBook Slides 5.0 alpha1 available for testing
Hi Gabor, A very promising start! Targeting Slidy is a great move too. Looking forward to making the switch! I suggest adding xsl:template match=*[namespace-uri()] xsl:copy-of select=./ /xsl:template to dbs3-upgrade.xsl to move over non-docbook content (MathML, SVG, ..., which the current script imports into the docbook namespace). There are some spacing and scaling issues with my own converted slides, but I'll hold it until you give the list green light for serious testing. I suspect that consistent content positioning (without using tables) between HTML and FO targets will require some thought. To this end, will slide-specific markup be part of your project? The current schema requires foil titles to be wrapped inside info. In contrast, DB5 allows section titles either inside or outside of an info (but not both). Having a title as the only info-type element inside a foil is such a common case that I think it should be allowed without info, just as it is in DB5 sections. I think incremental and collapsible should be properties of lists, not of slides, as they are in Slidy. I suspect you attached them to foil instead to avoid messing with the DocBook element content models. Actually, collapsible makes sense even for regular DocBook (at least for some output formats), not only for slides. Cheers, Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook-apps] generating pdf from DocBook slides
Stefan Seefeld ste...@seefeld.name wrote on Wed, 30 May 2012 14:50:18 -0400: As you also seem to have done quite some work on fo stylesheets to produce the slides that you were referring to in an earlier mail, perhaps you would also be willing to contribute your work back ? I have done mostly minor styling. Here are some issues I solved in my own customizations that I would like to see addressed: - create HTML5 video tags for movies - for movies, provide a way to specify parameters such as auto start Other customzations that might be useful to others but the inclusion of which in official DocBook I don't have strong feelings about: - environments for content that become visible on click (such as answers to questions) - my Speaker setup (https://iis.uibk.ac.at/public/piater/talks/speaker/speaker.xhtml) What I do care about in this context is the definition of a minimal but powerful set of presentational elements to make the most common slide layouts easy to create, as we have already discussed at length in this forum. Justus - 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] generating pdf from DocBook slides
honyk j.tosov...@email.cz wrote on Mon, 28 May 2012 23:03:56 +0200: I've tried to utilize Slides DTD for our training courses but quicky find the element suite too small and hence limiting me. Did you use slides or slides-full? The latter contains essentially all of DocBook. Justus - 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] generating pdf from DocBook slides
Hi Stefan, Why not use HTML for presentations? In 2003 I started off presenting DB Slides in PDF, but soon switched to HTML. To me it has many advantages and almost no drawbacks. I used to provide PDF slides to my students, but have stopped doing that in favor of reformatting my slides as a DocBook article using home-brew XSLT, with better text flow and additional content. Justus - 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] GSoC 2012 project proposal: DocBook Slides 5.0
Hi Gabor, Great to see progress in this direction! I have two suggestions: - Instead of starting with the S5 target, why not start by porting the existing targets? This should be much easier to do, and will allow people to migrate their slides. - Stefan, others and I have discussed presentational markup enhancements. I am still exited about these; there are ways to greatly simplify slide layout for the author. See http://lists.oasis-open.org/archives/docbook-apps/200901/msg00128.html and the entire thread. Best, Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook] GSoC 2011 project idea
Gabor Kovesdan ga...@kovesdan.org wrote on Sun, 06 Feb 2011 15:12:34 +: please vote for me. Here's a big, fat +1 from me (or is there a formal voting process somewhere?) I'm a DB-slides power user and would love to be able to move to DB 5. If you have spare capacities for this GSoC project (and I would guess so), why not use this opportunity to add some useful functionality to DB-slides? We had a lively discussion two years ago (http://lists.oasis-open.org/archives/docbook-apps/200901/threads.html#00053) with some interesting ideas, mostly contributed by Stefan, such as the introduction of a block/ element as a child of foil/ that would map to output elements that can be styled and positioned as desired. You'd make my day :-) Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
[docbook] def anywhere Re: [docbook] Feedback on DocBook Transclusion proposal
Dave Pawson da...@dpawson.co.uk wrote on Thu, 16 Dec 2010 19:55:17 +: On Thu, 16 Dec 2010 20:29:19 +0100 Jirka Kosek ji...@kosek.cz wrote: Of course it would be better to develop and use some more generic approach then to develop something specific to DocBook. The problem is that solution has to know which attributes are of ID/IDREF types -- it is hard to do this without schema introspection. ... My initial reaction is to restrict it to docbook, If implemented, and if it works well there, then perhaps look for wider adoption? Considering the complexity of the issue, I tend to agree with this viewpoint. Ultimately I would like to see transclusion become a first-class citizen of XML, perhaps using an xml* namespace to get around the ID/IDREF type issue. To make the already-complex proposal even more complex, I have an additional use case: As a heavy user of xinclude/xpointer, I routinely define reused content on the fly (mostly math, in practice). For example: article xmlns=http://docbook.org/ns/docbook; xmlns:xi=http://www.w3.org/2001/XInclude; titleTransclusion/title paraHere is a phrase role=cphrasecomplicated phrase/phrase that will reoccur several times./para paraFor example, here this xi:include xpointer=xpointer(//*...@role='cphrase'][1])/ occurs again./para paraAnd here, one more xi:include xpointer=xpointer(//*...@role='cphrase'][1])/./para /article (This XInclude notation is clearly a mess, and limits me to libxml2.) Now, how about *permitting the name attribute anywhere*, not only in def/ elements, allowing me to write equivalently: article xmlns=http://docbook.org/ns/docbook; titleTransclusion/title paraHere is a phrase name=cphrasecomplicated phrase/phrase that will reoccur several times./para paraFor example, here this ref name=cphrase/ occurs again./para paraAnd here, one more ref name=cphrase/./para /article Or, perhaps @def would be a better name for this attribute than @name. Of course, I could explicitly define the complicated expression via definitions/ as in Jirka's proposal. In practice however, ripping content out of their context is often inconvenient. It is often more natural to simply reuse the first occurrence in the text. Or even better, allow forward references as well. Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook-apps] Fop and SVG (Again): Good News for EPS = PDF Users
Tom Browder tom.brow...@gmail.com wrote on Fri, 3 Dec 2010 17:30:12 -0600: Apparently something is wrong with Inkscape's import and bounding box interpretation I suppose you know about Inkscape's Fit page to selection option in the Document Properties box? I've been using Inkscape for PDF-SVG conversion for a long time, consistently with near-perfect results. I do not have much experience with Inkscape for EPS-SVG conversion, but if there really is a problem, EPS-(Ghostscript)-PDF-(Inkscape)-SVG might be an alternative route. But thanks for sharing the hint about Scribus! Regards, Justus - 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] Announce: DocBook V5.1b2
Hi - What would it take to move docbook-slides forward to DocBook 5, including the namespace-stripping stylesheets (and one day hopefully DB5-native XSLT2 stylesheets)? The SVN appears to contain a 4-year-old initial step in this direction. How functional is it? I think I can maintain docbook-slides if nobody else is more eager, but since I've never looked closely at DB5 so far (for lack of slides support), I'd prefer to take over from an operational starting point. Norm? Thanks, Justus - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook-apps] equation display
David Cramer d.cra...@textechinc.us wrote on Sun, 29 Nov 2009 09:01:29 -0500: We need to be able to align specified equations on the equal sign (sometimes with intervening text), but I expect that's way too much to ask! Here's what I think is the essence of David's wish, which I share: the equivalent of a LaTeX eqnarray - a single math environment with multiple lines of math, each of them (optionally) numbered. I fear this goes beyond what the current DocBook+MathML integration can handle. Justus - 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] equation display
Hi - I barely ever see equations with titles and have never used one myself, so I cannot speak for aspects concerning titles. That said, all this looks perfectly reasonable to me, and would well serve the use cases in my field, in particular, 1. equation elements are numbered, and informalequation elements are not. These will be easily customizable like any other xrefs, as described in Ch. 15 of the Complete Guide, I take it: 6. An xref's generated text for a cross reference to an equation with title looks like this by default: Equation 3.2, My equation title 7. An xref's text for an equation without title looks like: Equation 3.2 Justus - 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] [Announcement] pMML2SVG: MathML to SVG via XSLT
pMML2SVG is a MathML-to-SVG converter coded in XSLT. Version 0.8, released today, handles a subset of MathML that covers many practical scenarios. The quality of its SVG output rivals that of many other MathML-to-SVG converters. It comes with XSLT stylesheets for transparent transformation of MathML embedded within XHTML and XSL-FO. As a practical usage example, these scripts are used in the creation of its XHTML and PDF documentation from DocBook sources. See http://pmml2svg.sourceforge.net/ for more information, examples, documentation, and downloads. Feedback is welcome! Justus - 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] slides: how to balance presentation and content
Stefan Seefeld seef...@sympatico.ca wrote on Fri, 23 Jan 2009 12:33:35 -0500: justus-b...@piater.name wrote: Oh. Really? Like, change the title font, slide background color, slide number position? No, but switch to a different layout. (Example: use a two-column layout in general, but switch to one-column layout for a particular slide containing a big graph. Etc.). OK, so we're after the same objective, for which I don't see a need to change anything at the foil level. All can be done with blocks, and quite intuitively, as I think my previous examples show. OOo Impress and friends use slide layouts, which correspond to foil layout=..., but I've always found this concept inappropriate. They're really just predefined arrangements of bulleted lists, graphics etc. in various combinations, while I would find it much more natural to simply insert such blocks individually, as I see fit. With something like this: foil block layout=left itemizedlist/ /block block layout=right mediaobject/ /block /foil you get the best of both worlds: A foil is always a foil, with all its default elements (title, navigation, footer, etc.). Its content is arranged in blocks that can be laid out and styled in predefined or individual ways. This is essentially your original example, but without the template attribute of foil. Why would that be needed? Moreover, limiting layout semantics to blocks makes it easy to allow nested blocks one day. whenever I want to display two images next to each other, the only way to achieve this is by stuffing them into a table. Being able to wrap both into a two-column layout slide makes the use of tables obsolete. Absolutely; this is what much of this thread has been about. block is a good name after all... One might use a layout or style attribute instead of name to make its function explicit. Yes, but such an attribute name would convey specific semantics, when all I want is identify the block so I can attach semantics (such as styling) externally (via CSS, for example). To me, attribute names that convey specific semantics are highly desirable. But besides the naming we're in full agreement here. Justus - 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] slides: how to balance presentation and content
Stefan Seefeld seef...@sympatico.ca wrote on Thu, 22 Jan 2009 10:48:05 -0500: justus-b...@piater.name wrote: I don't need to switch slide masters half-way through a presentation; do you? Yes. Oh. Really? Like, change the title font, slide background color, slide number position? In that case, why not add a master attribute to foil after all, which could trigger a different page-master for FO output. Referring to the issues cited below, after thinking about it, I think block is a good name after all. layout, style suggest that they *contain* layout or style definitions, which is of course not the case. One might use a layout or style attribute instead of name to make its function explicit. Do interested folks agree that we're headed towards something useful? One day I may actually contribute to an implementation of such a concept, as having it at hand would make my life easier. name is good I guess. layout name=twocol is very suggestive. cavicchio_...@emc.com wrote on Fri, 23 Jan 2009 10:38:53 -0500: justus-b...@piater.name [mailto:justus-b...@piater.name] wrote: Is it? To me, block seems overly general. Layout is very explicit in that it says I'm here for layout (and styling, etc.), not for semantic structure like all of my peers. Or style, as this term is used for all of this in CSS... Separating this from the issue of slides, I've often wanted to have a generic block element (like div), so that I could attach meta-data to an arbitrary collection of elements. Sometimes for layout purposes, sometimes not. I think there is semantic value in having a very generic container that basically says, These things all go together. - 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] slides: how to balance presentation and content
Stefan Seefeld seef...@sympatico.ca wrote on Wed, 21 Jan 2009 13:43:37 -0500: My expectation was that each slide models a given template, and a flexible and minimal way to achieve that through markup was to associate a template (by-name) with the foil, and then simply name the blocks, such that the stylesheets (CSS, in my case) would attach layout processing instructions to them. Yes. I like this, even though it covers only 90% of my needs. How about the following proposal, which builds on your ideas and accommodates both of our use cases: With respect to current docbook-slides, - Introduce a single new element called layout with (all optional) attributes master (in analogy to FO page-master, corresponding to a CSS class) name (corresponding to a CSS ID selector; is this really needed? Or use the XML id attribute instead of name?) and some layout attributes that are inspired by CSS property names. - Change the docbook-slides content model such that layout can be a child of foil. More generally, layout should probably be allowed in many other places where block-level elements are allowed. - Allow layout and existing block-level docbook elements as children of layout. (Or perhaps there is no need for nested layouts?) I think this is not very invasive, easy to understand, but extremely flexible: - The stock stylesheets might come with a default template for layout that does nothing in particular, and translates any layout attributes present into appropriate CSS, XSL-FO etc. One might also provide several default templates for commonly-used layouts (layout master=twocol), which would require reserving master names. - It would be easy to write custom XSLT templates (and associated CSS for XHTML output) for recurring layouts selected via the master attribute. Your custom XSLT template for two-column layout might expect exactly two children of the layout element, which the template puts into the left and right columns, e.g. by generating appropriate divs and CSS: foil layout master=twocol itemizedlist/ layout mediaobject/ mediaobject/ layout /layout layout master=footer/ /foil The same layout might be achieved more directly (and verbosely) in the following way, which for XHTML output would not require any custom XSLT (but would still require custom CSS) because the left and right could simply be passed through by the stock templates to the output XHTML as CSS class names: foil layout master=left itemizedlist/ /layout layout master=right mediaobject/ mediaobject/ /layout layout master=footer/ /foil - It would be easy to layout individual slides, without requiring any custom XSLT or CSS at all: foil layout top=2ex left=10% ... /layout layout bottom=10ex right=10em width=30% ... /layout /foil - Master and layout attributes might be combined, in which case the layout attributes would override the master style attributes, e.g. to achieve an asymmetric two-column layout. - Nested layouts would behave as nested HTML elements and cascaded styles do in CSS. Comments? Justus - 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] slides: how to balance presentation and content
Stefan Seefeld seef...@sympatico.ca wrote on Thu, 22 Jan 2009 09:52:58 -0500: * Your layout element may nest (it may appear wherever block-level elements are expected). Yes, but I'm not sure this is necessary. For simplicity, we should perhaps allow it only as a child of foil, without nesting, until somebody comes up with a well-motivated use case for nested layouts. Oh, here is one, from my previous message: foil layout master=twocol itemizedlist/ layout mediaobject/ mediaobject/ layout /layout layout master=footer/ /foil Perhaps not a very strong argument though. * Your layout element plays two roles at once: - It provides a handle to specify layout (as my 'blocks'), by means of the 'name' attribute. - It provides a handle to associate a template with it, by means of the 'master' attribute. I'm not sure whether mixing the two is really necessary. It might be clearer to only have them use 'name', but add the optional 'master' attribute to the top-level foil (or foilgroup) element. I also think we need only the one equivalent to CSS classes. I'm no longer sure master is a good name for this attribute because of its analogy to page masters, because I would not want them to be slide masters but rather slide body masters. I don't need to switch slide masters half-way through a presentation; do you? name is good I guess. layout name=twocol is very suggestive. This is also why I would steer clear from making master an attribute of foil; this would require a user to customize the foil template, or to use obscure XPath to react to ../@master or even ancestor::foil/@master. I think layout specifications belong inside the foil, not the a foil as such. Also, with that semantic simplification in mind, I like the name block' better than 'layout', as it better captures the elements intent. (You can apply a specific layout to it, as much as you can style it. That's capabilities typically associated with blocks in general.) Is it? To me, block seems overly general. Layout is very explicit in that it says I'm here for layout (and styling, etc.), not for semantic structure like all of my peers. Or style, as this term is used for all of this in CSS. But I don't have a very strong opinion here. ... I fully agree with the rest. Justus - 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] slides: how to balance presentation and content
No, that's not what I meant. All I'm saying is that people will want to migrate legacy content to DB 5 to take advantage of new features, so I argue against questioning each and every construct of the existing docbook-slides, and in favor of extending it, while being very careful and constructive with backward-incompatible changes. Of course, if there are good reasons to make backward-incompatible changes, may they be done. This *is* how DB 5 came about. Justus DavePawson da...@dpawson.co.uk wrote on Tue, 20 Jan 2009 18:30:15 +: So you'd like slides to remain static from now on, despite others wanting more from it? Just to keep your usage unchanged? - 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] slides: how to balance presentation and content
Stefan Seefeld seef...@sympatico.ca wrote on Tue, 20 Jan 2009 09:51:23 -0500: foil template=my-two-column-template block name=left itemizedlist/ /block block name=right mediaobject/ /block block name=footer/ /foil I see. Not bad. However, I would prefer to avoid element grammar to depend on attributes because this is not generally the way DocBook does it. This sort of layout can in principle be achieved using DocBook tables (CALS or HTML style), which is what I do, but it is unwieldy and cumbersome to adjust. Perhaps one way forward would be to think about simplified markup for tabular layouts whose semantics are inspired by tables but whose markup excludes all the cruft needed for real tables, e.g.: foil twocol block width=30% !-- content of left column -- /block block !-- content of right column -- /block /twocol /foil This would yield intuitive semantics, and stylesheets might reuse much of the table-related code. To this end, the first question is: What layout capabilities do we seek for presentations that cannot be achieved with tables? And here's my first answer: I'd often like to have a non-grid layout. Inspired by Stefan's suggestion, how about introducing the notion of a block that can be freely positioned on a page using CSS semantics, such as this: foil absolute block top=2ex left=10% ... /block block bottom=10ex right=10em width=30% ... /block /absolute /foil Here, the first question is: What subset (or adaptation) of CSS is reasonable, and also expressible in XSL-FO? Of course, this is a brutal departure from the XML principle of separation of content from presentation, but as I argued in an earlier posting, to me the advantages of (ab)using DocBook for presentations weigh far heavier than purity of principle. And of course, my two suggestions are meant to be part of a whole, not mutually exclusive. Justus digression I'm going to stay out of the discussion about incremental lists because I think they should never be used. I've never seen a *good* presentation that used them. It helps the audience to see the big picture while the speaker guides them through the details. Slides should support the talk, not the other way around. /digression - 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] slides: how to balance presentation and content
DavePawson da...@dpawson.co.uk wrote on Wed, 21 Jan 2009 15:45:21 +: Tables are for tabular data. Go read W3C accessibility guidelines. Tables are not for visual layout all over the screen. CSS does that nicely without messing with accessibility. It's the *HTML rendering* that has to be accessible, not the *DocBook source*. This discussion about accessibility and the appropriateness of tables for layout is irrelevant here. I did not propose to use tables for layout; I proposed new markup that borrows layout semantics (not HTML code) from tables. (Actually, I *did* implicitly and inadvertently propose to use HTML table code by suggesting the reuse of table-related XSLT templates. Here your point is well taken, Dave, and I withdraw that suggestion. Slide layout templates should indeed avoid using HTML tables as much as possible.) Stefan Seefeld seef...@sympatico.ca wrote on Wed, 21 Jan 2009 10:52:31 -0500: Oh I see. I guess Justus was suggesting a way to emulate (part of) the desired layout capabilities by means of existing markup. I agree that tables are a bit hackish (as they are in most cases in HTML). Not quite. I suggested a way of achieving (part of) the desired layout capabilities by means of new, dedicated markup with associated rendering expectations that borrow from table layout semantics. Exactly. And my suggestion to introduce some new 'box' markup was precisely meant to provide hooks similar to HTML divs, so somewhere else an appropriate layout could be attached to it. Somewhere else being an XSLT stylesheet? This would certainly be a clean way of doing it, but for me it would not significantly improve on the current situation. To me, a fundamental problem is that *many* slides require *individual* layouts. I don't want to write a customization layer for each presentation, containing individual layout details for many of the slides. The only way I currently see to coerce docbook-slides into a presentational system is to pull presentational markup into the XML source. To keep it minimally invasive, it could be restricted to be direct children of foil/foilgroup, so no actual DB vocabulary would be affected by it. I think it can make a lot of sense to add an extra wrapper, as I did in my example markup. It does not make it any more invasive, perhaps even less because in the worst case, all you need to do is change the existing docbook grammar to allow the new container elements as children of foil. All syntax variants and complicated XSLT are only ever associated with new elements, with hardly any need to change XSLT of existing elements. Another advantage of this approach is that you can push semantics up to the container element, making the markup more orthogonal: no need to tell both blocks that they are left and right, add threecol and relative layout, etc. Justus - 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] slides: how to balance presentation and content
For the same reasons DB 5 builds on DB 4: People have legacy content in DB4 docbook-slides and would like to migrate. I do, at least... Best, Justus DavePawson da...@dpawson.co.uk wrote on Tue, 20 Jan 2009 16:18:36 +: Why? - 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] slides: how to balance presentation and content
W. Martin Borgert deba...@debian.org wrote on Fri, 16 Jan 2009 20:51:57 +0100: Quoting Dave Pawson da...@dpawson.co.uk: W. Martin Borgert wrote: - An explicit element for speakernotes with divcomponentmix. Is that just another subdivision? E.g. ... Or do you want speakernotes at a higher level too? This should not be rediscussed in this context; we should keep the current content model of docbook-slides, port it to db5, and go from there. Justus - 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] slides: how to balance presentation and content
[limiting follow-up to docbook-apps] Stefan - For some years now I have been a heavy user of docbook-slides for presentations of all sorts, also using lots of MathML and SVG. MathML does not cause any problems for me. I preprocess my SVG content to include width=100%, height=100% and viewBox attributes in the root svg element; then, the graphics can nicely be scaled using the DocBook markup, so they are handled quite easily as well. But I share your experience that for presentations it is not easy to separate content from presentation (that's why they are called presentations I guess...). While I have greatly benefited from reusing content (using elaborate xi:includes), fine-tuning layout takes a lot of time. Thus, current attitude is that for quickly whipped-up, short-lived presentations (consortium meetings, some conference talks etc.) I increasingly use OOo Impress, whereas for long-lived and content-focused documents (course slides) I stick with docbook-slides. A mid-way compromise is the LaTeX beamer class. Not a very satisfactory solution, but I don't see how to fix this properly. Perhaps one pragmatic solution (purists shut your eyes!) might be to add presentational elements and attributes to a docbook-slides document model. I second the motion for a slides document model based on DB 5; its current absence is the only reason preventing me from moving to DB 5. Justus - 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] Docbook snapshots stalled?
Quote from http://docbook.sourceforge.net/snapshots/: The most recent build was of the xsl distribution, for revision , on 2008-12-16 at 2221 PST. - 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] orgame in preface/author html ??
This is a known bug with a proposed fix (hint, hint :-)): http://sourceforge.net/tracker/index.php?func=detailaid=2000787group_id=21935atid=373747 Justus Brett Gossage bgoss...@invariant-corp.com wrote on Tue, 30 Dec 2008 10:33:07 -0600: Using the 1.74 html stylesheets, my docbook preface info given below results in: John Q Foo Corporation Smith CTO Foo Corporation - 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] survey of DocBook 5.0 validation tools
I'm doing an informal survey for the DocBook Technical Committee regarding schema usage for DocBook 5.0. We would like to know among DocBook 5.0 users: 1. Which schema type are you using (RelaxNG, DTD, XML Schema) and why. RelaxNG, because it - is quite powerful and flexible - is very easy and intuitive to read and write - is straightfoward to customize - works with James Clark's nxml-mode for Emacs 2. What editing tools are you using, and why. Emacs, because I use Emacs for almost everything. nxml-mode, because it does many things for me, most importantly - on-the-fly validation - tag autocompletion - all the basic stuff (syntax highlighting, auto-indentation, ...) For me, its most serious shortcoming is the absence of built-in support for XIncludes (together with a choice of shallow and deep validation). I help myself with customized RelaxNG schemas where I allow xi:includes wherever I need them in practice. 3. What validation tools you are using, and why. - nxml-mode for on-the-fly, shallow validation (using schemas that allow xi:includes) - xmllint --xinclude followed by jing for deep validation (within an Emacs compilation buffer, of course) Why? The main reason is that I heavily use the xpointer() scheme (http://www.w3.org/TR/xptr-xpointer/) in my xi:includes, which is not widely implemented. This essentially limits me to libxml. Jing can use the same compact-syntax RelaxNG schema as uses nxml-mode. Justus - 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] Re: Docbook with Math ML/Latex = PDF
Dave Pawson [EMAIL PROTECTED] wrote on Thu, 23 Oct 2008 18:22:47 +0100: HTML I believe it's a browser feature? So is it reasonable to simply pass the mathml through to the html? Yes, and absolutely yes. Agreed there are no standards (yet). W3C seem very slow to get to grips with multi-namespaced documents. True, but recommendations and best practices have been around for many years; see e.g. http://www.w3.org/Math/XSL/Overview.html and http://www.w3.org/TR/XHTMLplusMathMLplusSVG/. Note that if you are willing to force Mozilla-based browsers upon your users, then you don't need to jump through any of the hoops set up in .../Overview.html; you simply include namespaced, inline MathML as outlined in the cited TR, which is what the DocBook XHTML stylesheets have been doing for a long time. MathML has been supported natively since Firefox 1, and in a very non-techie-user-friendly way since Firefox 3. Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Docbook with Math ML/Latex = PDF
Dean,
Here's a real-world example, copied (almost) straight from one of my
lectures:
informalequation
mediaobject
textobject role=tex
phrase![CDATA[
P(k \textrm{ heads in } n \textrm{ flips}) \;=\;
{n \choose k} p^k (1 - p)^{n-k}
]]/phrase
/textobject
textobject role=MathML
xi:include href=texmath/1775461169.xml/
/textobject
/mediaobject
/informalequation
I validate this shallowly through nxml-mode within emacs using my
own RelaxNG customization on top of docbook-rng-4.5/docbook.rnc which
essentially mixes in xinclude in strategic places, and includes
mathml2 in a way consistent (I think) with the official DocBook 4.5
MathML extension. For deep validation I use xmllint --nonet --noout
--xinclude --postvalid
Justus
[EMAIL PROTECTED] wrote on Mon, 20 Oct 2008 15:12:44 EDT:
All,
In my application, I need to do both PDF and HTML. I would like to do it
similar to a mediaobject and use role to differentiate the processign path
needed.
equation
mediaobject
imageobject role=html ./imageobject
textobject role=pdf **include the MML file *** /textobject
/mediaobject
/equation
Something like that. But what is the preferred way of including MathML in a
mediaobject? Or is there a more sane manner in which to go about this task?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Docbook with Math ML/Latex = PDF
DeanNelson [EMAIL PROTECTED] wrote on Tue, 21 Oct 2008 05:54:02 -0700: I am assuming that you have specific stylesheets to handle the MathML role? No, the stock stylesheets do the right thing: They simply pass the MathML subtree through to the output (for fo, wrapped insided an instream-foreign-object). I think it should work without any role attribute on the MathML-containing mediaobject child. Or perhaps one may need to set preferred.mediaobject.role appropriately to make sure the stylesheets pick up the right one. Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Docbook with Math ML/Latex = PDF
Dave Pawson [EMAIL PROTECTED] wrote on Mon, 20 Oct 2008 13:49:51 +0100: http://www.antennahouse.com/product/mathml.htm Nikolai has http://www.grigoriev.ru/svgmath/ I.e. mathml to SVG, then incorporate the SVG into docbook/fo There is also Apache FOP with the JEuclid FOP plugin. I have used both methods; both have minor quirks but are pretty usable and give satisfactory results for all of my current needs. I currently prefer the latter, as it requires fewer processing steps than svgmath. Then there is my own baby, http://sourceforge.net/projects/pmml2svg/, which seeks to provide an XSLT-only solution by converting MathML to SVG (for non-Gecko Web browsers, FOP without JEuclid, inkscape etc.). It is currently working as a proof of concept, and I have a student working on it, hoping to make it an attractive alternative by summer 2009. AFAIK there is no 'recommended' way to get mathml (either kind) embedded into docbook... yet. Yep. What I do is: - type individual variables and very short equations directly as mathml - type more lengthy math in LaTeX syntax into textobject role=tex directly into the docbook source, followed by a textobject role=html xi:include href=texmath/whatever.xml/ /textobject I have makefile-triggered scripts that create the whatever.xml using a standalone TeX-to-MathML converter. To reduce typing to a minimum, I use emacs-lisp code to create the docbook math environments ([inline]equation and subtrees). This setup works very efficiently for me now, but takes some setting up. Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Docbook with Math ML/Latex = PDF
Dave Pawson [EMAIL PROTECTED] wrote on Mon, 20 Oct 2008 16:08:54 +0100: Yes. Not very general purpose though is it? Granted. One should not have to resort to such complex setups. To me, MathML solves the issue of representation and rendering (thanks to the available MathML renderers); the remaining issue my setup tries to address is efficient manual entry of the rather verbose MathML. I'm assuming that docbook = html with embedded mathl is another route. That's what I do. Both PDF and XHTML are generated from the same DocBook XML + embedded (or xi:included), namespaced MathML. Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook] Re: Policy on backwards incompatible changes
Are backwards-incompatible changes really that destructive? Nobody forces anyone to upgrade their documents. One can easily install multiple versions of DocBook schemas in parallel. In contrast, maintaining multiple versions of stylesheets (to customize) is a pain. It seems to me that the real issue, rather than incompatible schema changes, concerns long-term support commitments to docbook constructs in the stylesheets. Thus, allow DocBook to move along at a reasonable pace, but commit to supporting DocBook constructs in the stylesheets for some time after they are phased out or changed. (However, this may occasionally require explicit triggering of old-style behavior through stylesheet parameters etc...) Justus Norman Walsh [EMAIL PROTECTED] wrote on Mon, 21 Jul 2008 10:52:07 -0400: ... there are established organizations with huge amounts of legacy DocBook content that don't move at internet speed. It would be rude, to say the least, if we moved so fast that they didn't have an opportunity to upgrade in an organized manner. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Conversion Problem between FO File to PDF Format using Slides DTD
Hi Tina, I submitted a bug report on this long ago (http://sourceforge.net/tracker/index.php?func=detailaid=1859831group_id=21935atid=373747), but it has not been fixed yet. I simply commented out the second, IMO redundant, calls of the anchor template in the two templates in question. This makes it work for me, and I have not observed any adverse side effects. Best, Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] FO processor support
Hi - I have the impression that I used to be one of the most serious PassiveTeX users out there, but I have now abandoned it in favor of Fop (trunk alias fop1). For me, PassiveTeX is a thing of the past. Are you (or is somebody else) going to port the slides stylesheets also? This would be greatly appreciated over here :-). Justus Norman Walsh [EMAIL PROTECTED] wrote on Wed, 12 Mar 2008 08:04:13 -0400: As I work on porting the XSLT 1.0 stylesheets to XSLT 2.0, I find workarounds, mostly for FOP and PassiveTeX scattered throughout. Does anyone know if these are still necessary? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] Slides PDF foilgroup titlepage problems
Hi, It appears that slides/fo/plain.xsl produces foilgroup title pages that display the foilgroup title twice, once as fo:static-content by the foil page master, and then as block content in inverted colors by the foilgroup.titlepage template. The appearance of the static-content title is probably a bug. As a quick fix, which might actually make some sense, I changed the select.user.pagemaster to use the slides-titlepage page master for foilgroups (instead of the foil page master). It would be nice to have the option of disabling foilgroup title pages altogether, but I did not find a simple way of doing this without flattening the hierarchical PDF bookmark structure. This is with Fop 0.94. Thanks, Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Using slides in FOP 0.94
Lars, I just switched my DocBook-Slides PDF toolchain to FOP 0.94 and did not run into this problem. Can you give a minimal DocBook-Slides example with no customizations that produces this error, the command line used to produce the .fo, and the version of your style sheets? Thanks, Justus [EMAIL PROTECTED] wrote on Mon, 14 Jan 2008 10:02:47 +0100: I have been successfully usinig slides together with FOP 0.25 but when I upgrade to the latest FOP version I get: 2008-jan-14 09:30:12 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement VARNING: Mismatch: flow (http://www.w3.org/1999/XSL/Format) vs. block (http:// www.w3.org/1999/XSL/Format) ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Slides for DocBook 5?
Hi Michael - Michael(tm) Smith [EMAIL PROTECTED] wrote on Tue, 14 Aug 2007 07:54:14 +0900: [EMAIL PROTECTED], 2007-08-13 17:52 +0200: I'd love to see a new docbook-slides package for DocBook 5 ... and functional stylesheets with the docbook-xsl-ns package. ... But I will discuss with Bob if we can try to get namespace support added to the Slides stylesheet for the 1.74.0 release. Any news? I use docbook-slides a lot, and it works so well for me (mainly because of the shared infrastructure (and content) with my non-slides docbook content) that I'm not going to abandon it anytime soon, even if I'm the only person on the globe who uses them. You guys are much better positioned than I to do the initial conversion. Once the tools are in a usable state, I could quite naturally do some of the maintenance myself if nobody else is sufficiently interested. As far as the stylesheets are concerned, rather than to keep reinventing wheels, maybe it is wiser to support instead a conversion tool to an existing, fancier HTML presentation system such as S5 (http://www.oasis-open.org/archives/docbook-apps/200701/msg00022.html)? What do the other browser-based presenters on this forum think? Thanks, Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] collection of docbook tags
Hello Hinrich, I'm not sure I understand your question, but I'll give it a shot: Hinrich Aue [EMAIL PROTECTED] wrote on Thu, 23 Aug 2007 14:34:31 +0200: is there a way in docbook to encapsulate other tags into a tag that has no structural meaning? The problem we are having is that we want to have several sections in an xml file, and xinclude it into another file. Is it that you do not really want to include it (the XML file) into another file, but rather all the sections contained therein? Then your problem might be solved by an XInclude with an appropriate xpointer attribute, something like this: xi:include xmlns:xi=http://www.w3.org/2001/XInclude; href=otherfile.xml xpointer=xpointer(article/section)/ where your sections are located in otherfile.xml: ?xml version='1.0' ? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; article section titleFirst Section/title paraContent./para /section section titleSecond Section/title paraMore content./para /section /article Hope this helps, Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook] Slides for DocBook 5?
Hi, What's the future of DocBook Slides? The docbook-xsl-ns-1.73.0 stylesheets contain a slides subdirectory, but it seems they do not work with the namespaced DocBook. There is, as far as I know, no slides schema to go with DocBook 5. I'd love to see a new docbook-slides package for DocBook 5 (and without the tools), and functional stylesheets with the docbook-xsl-ns package. Are there any such plans? Norm? Michael(tm)? Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] Announcement: The Speaker Slides Extension
I have been using DocBook slides for presentations and lecturing for several years now. In particular for lecturing (where, with growing experience, my slides become sparser, the blackboard denser, and the teaching more interactive), I've been missing the possibility of using my laptop to consult personal notes or access data or programs not for the audience to see. So I implemented the Speaker Slides Extension. The idea is to generate a flat file containing all slides for the speaker. The audience's view is displayed in a separate window (using Xinerama or a multihead display), and is updated via Javascript as the speaker navigates around in his view. I invite any interested parties to check out my self-documenting example at http://www.montefiore.ulg.ac.be/~piater/test/speaker/speaker.html, and to give me feedback. If it finds potential users other than myself, it might be useful to include it in the official docbook-slides distribution, where I'd be happy to maintain it for as long as I actively use it myself. Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Slides output formating
Pedro Pastor [EMAIL PROTECTED] wrote on Mon, 13 Aug 2007 16:27:09 +0200: Any clue about what’s going on? (I’m using Oxygen 8.2 tool, and the path to the source XML and to the main XSL are set in the “transformation scenario” environment). No, sorry, I use a completely different toolchain (emacs + xsltproc). Perhaps an XML catalog problem? I'm not sure the stylesheets exist at the given URLs, so you may need to make sure they are found locally via your XML catalogs. Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] Slides for DocBook 5?
Hi, What's the future of DocBook Slides? The docbook-xsl-ns-1.73.0 stylesheets contain a slides subdirectory, but it seems they do not work with the namespaced DocBook. There is, as far as I know, no slides schema to go with DocBook 5. I'd love to see a new docbook-slides package for DocBook 5 (and without the tools), and functional stylesheets with the docbook-xsl-ns package. Are there any such plans? Norm? Michael(tm)? Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Slides output formating
I can see a set of style-sheets for producing “Slides” as output. I know those are a customization layer of the HTML set It produces PDF output as well. While the stylesheets ship with the docbook-xsl package, for the schema you should download docbook-slides (the stylesheets therein are obsolete) and perhaps docbook-slides-demo. I’d like to read some text explaining how to use the “Slides” set and what should I expect as a result. For examples (slightly customized Docbook Slides based on Docbook 4.x), check my course Web pages (e.g., http://www.montefiore.ulg.ac.be/~piater/courses/INFO0013/notes/probability/index.xhtml; contains MathML and SVG). Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Slides output formating
Pedro, The docbook-slides-demo package should contain what you are looking for. Justus Pedro Pastor [EMAIL PROTECTED] wrote on Sun, 12 Aug 2007 15:00:03 +0200: The point is I don't know (and I cannot find) the How's-to for the Slide package. I mean: How should I organize my DocBook contents in order to have the appropriate Slides formatting (page layouts, etc). I think there should be some special directives and/or configuration files in order to define a slide show (something similar to the website XSL package). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] XSL and tex equations
Stefano Sabatini [EMAIL PROTECTED] wrote on Wed, 9 May 2007 11:38:19 +0200: I would like to avoid to use MathML, due to its need for a graphical editor, so using the compact tex notation You can have the best of both worlds (compact TeX-math syntax *and* MathML output): use a TeX-math-to-MathML translator. There are several options around. I have a setup that minimizes typing and manual intervention to almost nothing, described here: http://www.oasis-open.org/archives/docbook-apps/200402/msg00221.html Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] XInclude of part of current document
M.Canales.es [EMAIL PROTECTED] wrote on Thu, 5 Apr 2007 19:08:16 +0200: xpointer=xpointer(//[EMAIL PROTECTED]'string']) While this works, it produces an invalid document because the 'string' id is no longer unique (a nasty problem that occurs in various forms in conjunction with XInclude). But your XPath expression suggests that you do not use DTDs :-). Therefore, I usually resort to slightly more complicated XPaths that use @id to refer to the *parent* of the included element. Justus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
