Re: [docbook-apps] Syntax highlighting

2013-12-07 Thread Bob Stayton



On 12/6/2013 1:53 PM, Norman Walsh wrote:

...
As long as I'm airing dirty laundry, I'm also tempted to abandon the
XSL stylesheets and work instead on a purpose-built HTML+CSS rendering
for printing.


Hi Norm,

What composition engines do you have in mind for rendering HTML+CSS to 
print?


Bob Stayton
Sagehill Enterprises
b...@sagehill.net

-
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] HTML5 Audio + Video multiple sources

2013-12-07 Thread Peter Fleck

Hi all,

Is it possible in html5 output of audio and video to have multiple 
sources and fallback?


I'm thinking specifically of for example:

video
  source src=video.ogg type=video/ogg /
  source src=video.mp4 type=video/mp4 /
  source src=video.webm type= video/webm
/video

If tried different ways but haven't been able to do it yet, is it possible?

Many thanks,

Peter


Re: [docbook-apps] Syntax highlighting

2013-12-07 Thread Jirka Kosek
On 6.12.2013 22:53, Norman Walsh wrote:
 It appears that modern systems do this in the JavaScript layer on the
 client. They also use tables to render line numbers.
 
 I'm tempted to move in this direction. Comments?

I have used both approaches. Problem with Javascript one is that it
doesn't work for print (neither of XSL-FO, HTML/CSS composition egines
support Javascript) and sometimes introduces delay in rendering. On the
other hand Javascript syntax highlighters are in a more active
development then highlighting extensions for XSLT.

 As long as I'm airing dirty laundry, I'm also tempted to abandon the
 XSL stylesheets and work instead on a purpose-built HTML+CSS rendering
 for printing.

Do you mean completely removing existing incomplete fo code from project?

I think that we can keep code here in the case someone will have time
and interest to improve it further.

With HTML+CSS composition there is one big problem -- there is (at least
to my knowledge) no free renderer, I'm aware only of PrinceXML and
AntennaHouse.

But HTML+CSS printing got some traction recently, so it is wortwhile to
explore this area.

Jirka

-- 
--
  Jirka Kosek  e-mail: ji...@kosek.cz  http://xmlguru.cz
--
   Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
--
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
--
Bringing you XML Prague conferencehttp://xmlprague.cz
--



signature.asc
Description: OpenPGP digital signature


Re: [docbook-apps] Syntax highlighting

2013-12-07 Thread David Cramer
On 12/07/2013 01:38 AM, davep wrote:
 On 06/12/13 21:53, Norman Walsh wrote:
 Hello world,

 A fair bit of effort in the DocBook stylesheets goes into parsing,
 decomposing, annotating, and recomposing program listings for the
 purpose of adding line numbers to them. There's also a bunch of work
 that goes into syntax highlighting them.

 Occasionally, this takes a *long* time.

 It appears that modern systems do this in the JavaScript layer on the
 client. They also use tables to render line numbers.

We use the popular syntax highlighter:
https://github.com/alexgorbatchev/SyntaxHighlighter

But we had to adapt it to support callouts and markup inside the code
sample. Without our modifications, the js highlighter would end up
displaying the html markup from the inline markup and the callouts as if
it were part of the code sample. Here's an example of our version:

http://docs.rackspace.com/servers/api/v2/cs-devguide/content/curl_summary_xml.html

On the downside, it adds weight to the page.


 I'm tempted to move in this direction. Comments?
 
 
 No problem with line numbers. I guess it's the outcome we want
 rather than how it is done?
   Would that work with insertions too? E.g. lines with (6) etc
 which are referred to in commentary?

One caveat about using tables for line numbers. It generally makes it
impossible to cut and paste the code sample without getting all the line
numbers. One thing I like about the syntax highlighter above is that
when you click on the code sample, the callouts go away and are not copied.

Of course for pdf/print output, copy/paste is less of a concern.

Regards,
David

-
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] Syntax highlighting

2013-12-07 Thread Frank Arensmeier

 7 dec 2013 kl. 21:35 skrev Jirka Kosek ji...@kosek.cz:
 
 On 6.12.2013 22:53, Norman Walsh wrote:
 It appears that modern systems do this in the JavaScript layer on the
 client. They also use tables to render line numbers.
 
 I'm tempted to move in this direction. Comments?
 
 I have used both approaches. Problem with Javascript one is that it
 doesn't work for print (neither of XSL-FO, HTML/CSS composition egines
 support Javascript) and sometimes introduces delay in rendering. On the
 other hand Javascript syntax highlighters are in a more active
 development then highlighting extensions for XSLT.
 
 As long as I'm airing dirty laundry, I'm also tempted to abandon the
 XSL stylesheets and work instead on a purpose-built HTML+CSS rendering
 for printing.
 
 Do you mean completely removing existing incomplete fo code from project?
 
 I think that we can keep code here in the case someone will have time
 and interest to improve it further.
 
 With HTML+CSS composition there is one big problem -- there is (at least
 to my knowledge) no free renderer, I'm aware only of PrinceXML and
 AntennaHouse.

Actually, there is a renderer that is able to generate PDF from HTML with 
really good results. Wkhtmltopdf (https://code.google.com/p/wkhtmltopdf/). It's 
basically a wrapper for the WebKit engine used by safari, chrome etc. Not sure 
if the WebKit they are using right now is bleeding edge. Anyway, it produces 
quite decent PDFs. 

I would definitely vote for the HTML route. Styling printable output with CSS 
would make the whole development process much more easier and less time 
consuming than it is today with XSL.

/frank

 
 But HTML+CSS printing got some traction recently, so it is wortwhile to
 explore this area.
 
Jirka
 
 -- 
 --
  Jirka Kosek  e-mail: ji...@kosek.cz  http://xmlguru.cz
 --
   Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
 --
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
 --
Bringing you XML Prague conferencehttp://xmlprague.cz
 --
 

-
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] Syntax highlighting

2013-12-07 Thread Jirka Kosek
On 7.12.2013 23:05, Frank Arensmeier wrote:
 Actually, there is a renderer that is able to generate PDF from HTML with 
 really good results. Wkhtmltopdf (https://code.google.com/p/wkhtmltopdf/). 
 It's basically a wrapper for the WebKit engine used by safari, chrome etc. 
 Not sure if the WebKit they are using right now is bleeding edge. Anyway, it 
 produces quite decent PDFs. 
 
 I would definitely vote for the HTML route. Styling printable output with CSS 
 would make the whole development process much more easier and less time 
 consuming than it is today with XSL.

AFAIK web browsers, including those based on webkit, doesn't support
CSS3 modules that add basic features necessary for print output, e.g.:

https://bugs.webkit.org/show_bug.cgi?id=85062

-- 
--
  Jirka Kosek  e-mail: ji...@kosek.cz  http://xmlguru.cz
--
   Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
--
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
--
Bringing you XML Prague conferencehttp://xmlprague.cz
--



signature.asc
Description: OpenPGP digital signature


Re: [docbook-apps] HTML5 Audio + Video multiple sources

2013-12-07 Thread Bob Stayton

Hi Peter,
This is not yet supported in the stylesheets. It could be, but I'm not 
sure what the DocBook markup should be.  The mediaobject element 
currently allows multiple videoobject children, but the stylesheet 
currently selects only one object for output from mediaobject, based on 
the role attribute on the object elements.  That lets you specify one 
videoobject for HTML5 output and a different one for epub3 output, and 
an imageobject for print output.


If the videoobject allowed multiple videodata elements, then it could 
output all of them as in your example, mapping the fileref attribute to 
@src and the format attribute to @type, for example.  But that currently 
is not allowed in DocBook.  If you were to file an RFE on the 
SourceForge DocBook page, then it would be considered by the DocBook 
Technical Committee.


Any other suggestions for a markup scheme?

--
Bob Stayton
Sagehill Enterprises
b...@sagehill.net

On 12/7/2013 12:27 PM, Peter Fleck wrote:

Hi all,

Is it possible in html5 output of audio and video to have multiple
sources and fallback?

I'm thinking specifically of for example:

video
   source src=video.ogg type=video/ogg /
   source src=video.mp4 type=video/mp4 /
   source src=video.webm type= video/webm
/video

If tried different ways but haven't been able to do it yet, is it possible?

Many thanks,

Peter




-
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] Syntax highlighting

2013-12-07 Thread Mike Maxwell

On 12/7/2013 5:05 PM, Frank Arensmeier wrote:

Actually, there is a renderer that is able to generate PDF from HTML with 
really good results.
Wkhtmltopdf (https://code.google.com/p/wkhtmltopdf/).


There's also htmltolatex (with LaTeX to create the PDF):
   http://htmltolatex.sourceforge.net/
I'm not sure how it handles character encodings; I would guess that it could be 
made to preserve
UTF-8 (rather than substituting special LaTeX names), in which case you could 
use XeLaTeX to produce
the PDF.
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org