[docbook-apps] mediaobject with base64 encoded image data
Good morning, We plan to XSL transform a dynamically generated docbook including images to FO and subsequently process that to PDF. Therefore I'm digging only in the docbook to FO stylesheets. While investigating that we had the idea to base64 encode images and include them in the docbook because it enables us to bypass image caching while generating PDF on the fly. To include a base64 image I had the idea to write it as: -- quote -- docbook:figure docbook:titleSample/docbook:title docbook:mediaobject docbook:imageobject fo:external-graphic src=data:image/jpeg;base64,XYZ width=auto height=auto content-width=auto content-height=auto content-type=content-type:image/jpeg / /docbook:imageobject /docbook:mediaobject /docbook:figure -- /quote -- But unfortunately the stylesheet (1.75.2 release) would wrap that within a fo:instream-foreign-object / and that causes the FO processor to fail including the base64 encoded image. Therefore I changed the docbook xsl stylesheet (based on the 1.75.2 release) in the file fo/graphics.xsl slightly: -- diffquote -- xsl:template match=imageobject xsl:choose xsl:when test=imagedata xsl:apply-templates select=imagedata/ /xsl:when +xsl:when test=fo:external-graphic + xsl:apply-templates mode=copy-all / +/xsl:when xsl:otherwise fo:instream-foreign-object xsl:apply-templates mode=copy-all/ /fo:instream-foreign-object /xsl:otherwise /xsl:choose /xsl:template -- /diffquote -- This patch drops the fo:instream-foreign-object / tag when encountering fo:external-graphic /. Does this patch break other things? Would you guys do it somehow different? Cheers, Dominik - 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] mediaobject with base64 encoded image data
Hi Bob, thanks for the feedback. I looked into 4 alternatives: 1) IBEX At the moment our choice because it's relatively cheap, fast and even though it produces quite large PDF files (double size in respect to the Antenna House implementation) it is not a KO criteria for IBEX. 2) Antenna House This is the most expensive option. We won't spend that much unless we run into serious trouble with IBEX (bugs, etc..). 3) FO.NET Did not pass all tests and is poorly supported - well - it is free. :-) 4) FOP This would be my favourite, but unfortunately we cannot depend on a java application. Going back to the customization, you wouldn't do the previously mentioned customization differently, would you? I'm asking because I also thought about integrating base64-encoded imagedata better into docbook by: 1) either creating a fresh new attribute like src on the imagedata / tag that could be passed on to the respective FO attribute src in the tag fo:external-graphic /. 2) or parsing the fileref attribute and don't wrap it in url() if it starts with imagedata. Both 1) and 2) feel much more like the right solution that could also become a patch that could be applied on the next release of the docbook stylesheets. What do you think about that? Cheers, Dominik -Original Message- From: Bob Stayton [mailto:b...@sagehill.net] Sent: Monday, April 02, 2012 6:39 PM To: Dominik Psenner; docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] mediaobject with base64 encoded image data Hi, That customization looks fine to me. What XSL-FO processor are you using? Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Dominik Psenner dpsen...@gmail.com To: docbook-apps@lists.oasis-open.org Sent: Monday, April 02, 2012 12:30 AM Subject: [docbook-apps] mediaobject with base64 encoded image data Good morning, We plan to XSL transform a dynamically generated docbook including images to FO and subsequently process that to PDF. Therefore I'm digging only in the docbook to FO stylesheets. While investigating that we had the idea to base64 encode images and include them in the docbook because it enables us to bypass image caching while generating PDF on the fly. To include a base64 image I had the idea to write it as: -- quote -- docbook:figure docbook:titleSample/docbook:title docbook:mediaobject docbook:imageobject fo:external-graphic src=data:image/jpeg;base64,XYZ width=auto height=auto content-width=auto content-height=auto content-type=content-type:image/jpeg / /docbook:imageobject /docbook:mediaobject /docbook:figure -- /quote -- But unfortunately the stylesheet (1.75.2 release) would wrap that within a fo:instream-foreign-object / and that causes the FO processor to fail including the base64 encoded image. Therefore I changed the docbook xsl stylesheet (based on the 1.75.2 release) in the file fo/graphics.xsl slightly: -- diffquote -- xsl:template match=imageobject xsl:choose xsl:when test=imagedata xsl:apply-templates select=imagedata/ /xsl:when +xsl:when test=fo:external-graphic + xsl:apply-templates mode=copy-all / +/xsl:when xsl:otherwise fo:instream-foreign-object xsl:apply-templates mode=copy-all/ /fo:instream-foreign-object /xsl:otherwise /xsl:choose /xsl:template -- /diffquote -- This patch drops the fo:instream-foreign-object / tag when encountering fo:external-graphic /. Does this patch break other things? Would you guys do it somehow different? Cheers, Dominik - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - 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] mediaobject with base64 encoded image data
-Original Message- From: Jirka Kosek [mailto:ji...@kosek.cz] Sent: Tuesday, April 03, 2012 9:43 AM To: Dominik Psenner Cc: 'Bob Stayton'; docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] mediaobject with base64 encoded image data On 3.4.2012 8:38, Dominik Psenner wrote: I'm asking because I also thought about integrating base64-encoded imagedata better into docbook by: 1) either creating a fresh new attribute like src on the imagedata / tag that could be passed on to the respective FO attribute src in the tag fo:external-graphic /. 2) or parsing the fileref attribute and don't wrap it in url() if it starts with imagedata. There is no need to change anything on DocBook side to support this. Simply put data: into fileref attribute. That doesn't work together with the IBEX processor because data:.. is wrapped into url(data:..) and then the processor treats data:.. as an url, which it is not and thus the image is not rendered as the data of the image can't be retrieved from the path data:.. unless it exists by coincidence. There migh be needed some small changes in XSL stylesheets in order to skip usual file path massaging. That would be the template named fo-external-image in graphics.xsl, isn't it? Also I think that even data: should be wrapped in url() otherwise it would be non-conforming to XSL-FO spec. At least the implemented IBEX interpretation of the XSL-FO spec doesn't behave like that. Cheers, Dominik - 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] mediaobject with base64 encoded image data
There is no need to change anything on DocBook side to support this.
Simply put data: into fileref attribute.
That doesn't work together with the IBEX processor because data:.. is
wrapped into url(data:..) and then the processor treats data:.. as an
url, which it is not and thus the image is not rendered as the data of
the
image can't be retrieved from the path data:.. unless it exists by
coincidence.
But data: is URL, see http://www.ietf.org/rfc/rfc2397
I see. I'm going to ask them a few stupid questions. :-)
If IBEX can handle this, then it is clearly IBEX bug.
There migh be needed some small
changes in XSL stylesheets in order to skip usual file path massaging.
That would be the template named fo-external-image in graphics.xsl,
isn't
it?
No, it's
xsl:template name=image.src
xsl:param name=filename/
xsl:choose
xsl:when test=svg:* xmlns:svg=http://www.w3.org/2000/svg;
!-- no src attribute for inline SVG content --
/xsl:when
xsl:when test=mml:* xmlns:mml=http://www.w3.org/1998/Math/MathML;
!-- no src attribute for inline MathML content --
/xsl:when
xsl:otherwise
xsl:call-template name=fo-external-image
xsl:with-param name=filename
xsl:if test=$img.src.path != '' and
not(starts-with($filename, '/')) and
not(contains($filename, '://'))
xsl:value-of select=$img.src.path/
/xsl:if
xsl:value-of select=$filename/
/xsl:with-param
/xsl:call-template
/xsl:otherwise
/xsl:choose
/xsl:template
Test should be added not to prepend img.src.path when $filename starts
with data:
Also there are other places where extension functions to measure image
are invoked. They probably need some modification as well.
Also I think that even data: should be wrapped in url() otherwise it
would be non-conforming to XSL-FO spec.
At least the implemented IBEX interpretation of the XSL-FO spec doesn't
behave like that.
It's not only IBEX, you can modify existing template and compensate for
IBEX as well:
xsl:template name=fo-external-image
xsl:param name=filename/
xsl:choose
xsl:when test=$passivetex.extensions != 0
or $fop.extensions != 0
xsl:value-of select=$filename/
/xsl:when
xsl:otherwise
xsl:value-of select=concat('url(', $filename, ')')/
/xsl:otherwise
/xsl:choose
/xsl:template
Just add $ibex.extension and omit url() if it is set to 1.
Thanks a lot for the clarifications. Now I understand why there's this test.
For now I won't dive into further modifications to compensate the errors of
others. :-) But I will keep this in mind as another possible solution.
Cheers,
Dominik
-
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] can I move the table of contents?
Good morning Lorenzo. I'm taking this to the right mailing list (see recipient). You'll be using some sort of docbook stylesheets to transform the docbook document into your output format (.html, .pdf, .fo, ..). A common implementation is located at http://docbook.sf.net/release/xsl/current/. Taking that implementation as reference, if you for example would use the HTML xsl-stylesheets to generate your output, you would find a file at html/index.xsl with the comment: !-- some implementations use completely empty index tags to indicate -- !-- where an automatically generated index should be inserted. so -- !-- if the index is completely empty, skip it. Unless generate.index -- !-- is non-zero, in which case, this is where the automatically -- !-- generated index should go. -- Interpreting this would take me to assume that I could place an empty index tag (index /) somewhere in my docbook document and by setting the parameter $generate.index to 1 would then generate it in that place and only there. But I haven't tried this. Good luck! :-) Cheers, Dominik -Original Message- From: Lorenzo Caminiti [mailto:lorcamin...@gmail.com] Sent: Thursday, April 19, 2012 1:29 AM To: docb...@lists.oasis-open.org Subject: [docbook] can I move the table of contents? Hello all, This is my very first post on this ML. My question: Is there a way I can specify to generate the Table of Contents within a specific section instead that at very beginning of the document? (For example, some DocBook XSL option...) I'm using Boost.QuickBook as a front-end to generate DocBook documents in HTML. The Table of Contents automatically shows up at the very top of the very first HTML document. I'd like to move it to later in the document. Thanks a lot. --Lorenzo - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org - 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] Making PDFs in Windows
Hi We're transforming docbook documents to FO using the .NET library classes XmlReader and XslCompiledTransform in the namespace System.Xml and System.Xml.Xsl. The resulting formatting objects are then processed to PDF by the commercial IBEX product. We used to call FOP before but we had to drop that because of the java dependency. The open source processors that we evualuated (besides FOP) were all not fit enough for production releases - therefore the dependency on the commercial product. Cheers, Dominik _ From: Paul Tremblay [mailto:paulhtremb...@gmail.com] Sent: Thursday, April 19, 2012 3:11 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Making PDFs in Windows I have used both cygwin and mingw. I prefer mingw because cygwin has so many bugs, and in fact the latest version does not work with the FOP bash script. However, as others pointed out, you can generate PDF from the windows shell. I prefer not to use the Windows shell because it has so many limitation compared to a unix-like shell. Paul On 4/18/12 9:59 AM, deannel...@aol.com wrote: Its not necessary to use Cygwin or MinGW. I use a batch file that calls XSLTPROC and FOP to generate PDFs under Windows. Check our Bob Stayton's book for more info. Regards, Dean Nelson In a message dated 4/18/2012 6:51:52 A.M. Pacific Daylight Time, yoursurrogate...@gmail.com writes: Hi guys, have you ever used Docbook to generate PDFs in Windows? Did you use Cygwin? If not, would you recommend anything else?
RE: [docbook-apps] can I move the table of contents?
Dominik, if I understood it correctly, Lorenzo talks about the table of contents, not the index. :) OFFTOPIC *laughingly* I never quite got the differences between TOC, indexes and bibliographies. To me they are all the same thing with different flavours. :-) /OFFTOPIC - 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] Image maps in PDF output
Hi Tyson, In general docbook documents are transformed to an intermediate representation before they are processed to pdf. The intermediate representation is FO (formatting objects). Have you tried to write down a couple of formatting objects (FO) that FOP is capable of processing them to pdf as you want? If you were able to do that, it shouldn't be much work to put that stuff into the right place within a docbook document and adapt the respective stylesheets to process that data so that it will work in the future. Cheers, Dominik -Original Message- From: Tyson Marchuk [mailto:tmarc...@cdlsystems.com] Sent: Monday, May 07, 2012 4:29 PM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Image maps in PDF output Hi Bob, Thank you. I guess I'll have to do something else then if hotspots on graphics are not supported in PDFs. I did some more searching and apparently PDFs do support this (http://www.authorst.com/hot_graphics_in_pdf_file.php) so I guess it is a limitation of the DocBook XSL to PDF conversion (which I guess is what you're saying below although I don't quite understand the concept of extensions in this context.) Thank you for your time, -Tyson On 2012/05/06 1:00 AM, Bob Stayton wrote: Hi Tyson, That message you referred to did not cover imagemaps. It was referring to using callout icons in a programlisting. In that case, an extension function is needed to preprocess the text in the programlisting to place the callout images in with the text, and that mix is then processed by DocBook XSL into PDF output. There is no equivalent extension for mixing callouts or other hot spots with images, as far as I know. I hope someone proves me wrong. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Tyson Marchuk tmarc...@cdlsystems.com To: docbook-apps@lists.oasis-open.org Sent: Friday, May 04, 2012 4:09 PM Subject: [docbook-apps] Image maps in PDF output Hello, I'm new to Docbook and I'm trying to create an image map (click-able image where clicking different sections of the image results in going to different locations in the document) in a PDF document. I've run across this reference (http://www.sagehill.net/docbookxsl/Imagemaps.html) which seems to suggest this can't be done in PDFs with Docbook but it was published in 2007 and I saw a post on this mailing list from 2012 (http://lists.oasis-open.org/archives/docbook-apps/201202/msg00010.html) which seems to suggest it should work in PDFs. I've used the example code from the first link with slight modifications (copied below) on one of my graphics and changed the stylesheet to only use numbers and while the output does have the numbers and text below the graphic there does not appear to be any linking going on in the document between the graphic and callouts. Is this a limitation of PDFs or Docbook or am I doing something wrong? Thank you for your time and help, Tyson Marchuk mediaobjectco imageobjectco areaspec id=map1 units=calspair area linkends=callout1 coords=0,0 5000,1 id=area1/ area linkends=callout2 coords=5000,0 1,1 id=area2/ /areaspec imageobject imagedata fileref=images/myImage.png / /imageobject calloutlist callout arearefs=area1 id=callout1 paraMy only callout1/para /callout callout arearefs=area2 id=callout2 paraMy only callout2/para /callout /calloutlist /imageobjectco /mediaobjectco - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - 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] Aligning numbers in table cells with xsl
Hi Dave,
that should work with a straight forward xsl:choose statement and the XSL
functions number(), string-length() and substring() to convert your string
to a double.
I.e. something like:
xsl:template name=StrToNumber
xsl:param name=str /
xsl:choose
xsl:when test=starts-with($str, 'lt;') or starts-with($str,
'gt;')
xsl:value-of select=number(substring($str,
string-length('lt;X'))) /
/xsl:when
xsl:otherwise
xsl:value-of select=number($str) /
/xsl:otherwise
/xsl:if
/xsl:template
Extensive testing is left to the reader. :-)
Cheers,
Dominik
_
From: Xmplar [mailto:i...@xmplar.biz]
Sent: Friday, May 25, 2012 4:39 AM
To: Bob Stayton
Cc: DocBook Apps
Subject: Re: [docbook-apps] Aligning numbers in table cells with xsl
I managed to (almost) fix the problem by adding a test for NaN to the string
variable:
xsl:if test=(ancestor-or-self::d:table/@tabstyle = 'numbers' or
ancestor-or-self::d:table/@tabstyle = 'numberstripe') and
not(ancestor::d:thead or
ancestor::d:tfoot) and preceding-sibling::d:entry and
(string(number(.) != 'NaN'))
This however will not select any cells that have a number and a non-numeric
string (such as greater than or less than signs: 1, or 20) - my test
treats those cells as a string and not as a number. I now need to find how
to convert lt; and gt; to a number so that the test selects cells with a
number and a lt or gt sign.
On 24-05-12 4:24 PM, Bob Stayton wrote:
xsl:if test=(ancestor-or-self::d:table/@tabstyle = 'numbers' or
ancestor-or-self::d:table/@tabstyle = 'numberstripe') and
not(ancestor::d:thead or
ancestor::d:tfoot) and preceding-sibling::d:entry and
string(number(.))
--
Dave Gardiner
Xmplar
i...@xmplar.biz
http://xmplar.biz
Mob. 0416 833 993
Re: [docbook-apps] Gradle build cross-platform - trouble with Saxon 6.5.5 params under Windows
2017-08-10 8:30 GMT+02:00 Dave Pawson <dave.paw...@gmail.com>: > Worth asking on the docbook-apps list Peter? > This is the docbooks-apps list, isn't it? > I use 2 for other parts, but for my main (quite large) docbook build I use > 1. > I use ant. > HTH > Peter, you could try giving "-o" and "myoutputfile.xml" as separate arguments. If you would build this with Go-Cd, it would require you to configure the build task arguments like this: ``` --some-other-arg -o myoutputfile.xml ``` and thus treating every line as a separate argument. Writing it like this would not work: ``` --some-other-arg -o myoutputfile.xml ``` You could also try wrapping `myoutputfile.xml` in quotes. > > On 10 August 2017 at 05:14, Peter Desjardins > <peter.desjardins...@gmail.com> wrote: > > Hi! I have a working Gradle build system that transforms DocBook 5.1 > > (using an assembly) to a few output mediums. I'm using Saxon 6.5.5 and > > the DocBook XSLT 1.0 stylesheets (latest version). When a new writer > > chose to use Windows, the Gradle build broke when she ran it locally. > > > > Problem #1 is that the Gradle exec task that assembles the DocBook > > assembly using Saxon 6.5.5 won't work under Windows. Saxon complains > > that there's "no output file name." Gradle has a terrible problem > > consuming the "-o myoutputfile.xml" argument. If I present the "-o" > > argument separately, Saxon claims that the output file name is > > missing. If I present a "-o myoutputfile.xml" argument, Saxon > > complains that "-o myoutputfile.xml" isn't a recognized argument. Has > > anyone built a Gradle Exec task that runs Saxon 6.5.5 on Windows? It > > works just fine on Linux and MacOS. > > > > Question #2 is: Has anyone had trouble using Saxon9HE with the DocBook > > XSLT v1.0 stylesheets? The way the arguments for the later version of > > Saxon are structured work much better with Gradle. > > (-o:myoutputfile.xml.) > > > > I'm considering switching to the DocBook XSLT 2.0 stylesheets to work > > around this problem. That avoids mixing Saxon9HE with the DocBook XSLT > > 1.0 stylesheets. Has anyone had any trouble migrating to XSLT 2.0? > > > > Thanks for your help! > > > > Peter > > > > - > > To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org > > For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org > > > > > > -- > Dave Pawson > XSLT XSL-FO FAQ. > Docbook FAQ. > http://www.dpawson.co.uk > > - > To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org > > -- Dominik Psenner
