RE: [docbook-apps] UI strings vs manual strings ?
On 05/12/2022 23:05, Jean-Christophe Helary wrote: > What's the best way in a DocBook centered process to ensure that the > list of terms used in a software UI is (semi-automatically?) taken > into account in the DocBook sources that describe that software? In your document you can use and other
RE: [docbook-apps] Multiplatform toolchain for outputting "nice" PDF
On November 14, 2022 Jean-Christophe wrote: > Currently, the PDF that's built from our DocBook set is, not visually > pleasant, to say the least. When generating outputs you are usually pushed to follow the corporate identity. And it is IMHO easier extending the minimalistic default style than overriding more complex one. You can achieve really outstanding outputs, but it requires advanced XSLT and XSL-FO skills and also a decent understanding of how DocBook stylesheets are structured and layered. All this can work with your current toolset. You can start here: http://www.sagehill.net/docbookxsl/CustomizingPart.html But before diving into the new world, keep in mind PDF has fundamental limitations and its use is decreasing. In our company, it is currently being phased out because: - for REST API descriptions we cannot offer the same level of interactivity as in case HTML outputs (collapsing sections, selecting examples from the dropdown list) - examples in method descriptions have limited width so lines have to be wrapped, but sometimes you have to break the word and put a special hyphen character there; such examples cannot be copied/pasted directly into your code - nowadays people open PDF files usually directly in the browser. Chrome cannot load the file progressively (like Firefox can) so in case of larger file you have to wait until the file is fully downloaded. The file has to be parsed and converted into DOM and set of CSS styles, which is far less efficient than feeding the browser with HTML + CSS directly. - accessibility: PDF engine is a blackbox and you have limited control over the final PDF structure to optimize it for screen readers or fulfill WCAG and Section 508 requirements - problematic support for videos (especially those with subtitles or transcriptions) Regards, Jan - 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] Relative paths when processing DocBook 5 with DocBook 4 stylesheets
On 2019-06-14 Jirka Kosek wrote: > On 11.6.2019 23:19, Jan Tosovsky wrote: > > In my case all relative images has become absolute. > > Or are there better/built-in ways? > > Well this is tricky area. I would suggest switching to "ns" flavour of > stylesheets where there is no such problem. I apply same heavily customized stylesheets to both DB4/DB5 documents. I am afraid there is no ROI for rewriting styles to NS variant and then to maintain both versions. > > Alternatively you can see whether the following parameter would work in > your case: > > http://docbook.sourceforge.net/release/xsl/current/doc/html/keep.relativ > e.image.uris.html This could work in some environments, but not applicable in documents composed from XIncludes located in nested subfolders. In my new customization I am tweaking . Once the image file path is determined, it is then truncated using $base.dir parameter (with some additional processing specific to my environment). Jan - 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] Relative paths when processing DocBook 5 with DocBook 4 stylesheets
Dear All, I am facing relative path issue described in http://www.sagehill.net/docbookxsl/ProcesingDb5.html : >> The disadvantages of [DocBook 4] stylesheets for DocBook 5 are: >> - The act of copying the content into a node set loses the base URI of the document. This can create problems with relative path references for images ... In my case all relative images has become absolute. I can imagine to override template located in /common/common.xsl, which would simply remove the prefix passed as a template parameter. Or are there better/built-in ways? Thanks, Jan - 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] page numbers are not right aligned
On 2018-11-26 Bob Stayton wrote: > The more general case with dot leaders and right alignment is an > inresolved FOP bug: > > https://issues.apache.org/jira/browse/FOP-1839 > IIRC this problem can be eliminated if outer spaces around the dots are replaced with leaders of fixed width. The standard space is stretching element thus hard to calculate properly if there are too many variables to handle. So in it could be modified like this: dots 3pt 0.5pt Regards, Jan - 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] Capital latin "Q" with dot above
On 2018-06-11 oa...@docbook-autor.de wrote: > > as it seems there isn't an entity for a capital latin "Q" with a dot > above like . > > I'm wondering how to realise generic diacritical marks with DocBook > (besides using an inline image...). You cannot combine multiple characters to form the composed one. If there is Unicode character for this combination, you can use it directly. If it is not displayed correctly, it means your font doesn't contain this character and you need to switch to the font with broader character support. If there is no suitable Unicode character nor appropriate font, the only way is to use the inline image, ideally vector one, e.g. SVG. HTH, Jan - 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] Japanese index
On 2018-04-25 Jirka Kosek wrote: > On 25.4.2018 11:57, Tony Graham wrote: > > Sorry, but I've never used it, so all that I know is what's on the website. > > I see. After digging some old emails I have been able to find this link: > > https://www.antennahouse.com/i18n-support-library-2/ > > It contains open-source part of library that should be working with > "kimber" method in the stylesheets. This could provide Jan with correct > Japanese indexing. Oops, I've forgotten there are other indexing methods. That 'kimber' looks very promising. Thanks a lot for the link to the Saxon extension. The original link at http://www.sagehill.net/docbookxsl/IndexIntl.html is broken now. If I understand correctly, comparing the open-source version 1 and the version 2, the latter brings enhancements in Chinese sorting and support for additional languages. Both is not directly related to Japanese so I'll start with that open source version. Thanks, Jan - 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] Japanese index
Dear All, has anybody any experience with generating Japanese back-of-the-book index from DocBook source? I am facing same issues discussed in this old thread (all entries end up in the Symbols section): https://lists.oasis-open.org/archives/docbook-apps/200605/msg00063.html If I understand correctly, indices in Japanese should be grouped phonetically: https://www.slideshare.net/k16shikano/imybp-light I've found promising Kuromoji library https://github.com/atilika/kuromoji I can imagine it could somehow pre-process all index entries and generate values for the 'sortas' attribute. But it is still unclear how to tweak the index code to generate groups from non-latin characters. Or are there better ways? Thanks, Jan - 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] REST API description
On 2017-12-07 David Cramer wrote: > On 2017-12-05 Jan Tosovsky wrote: > > Is there any recommended DocBook tag set for describing REST API? > > I don't think DocBook is the right vocabulary for modeling a REST API. > There's an XML schema, WADL (Web Application Description Language) that > is designed for that > ... > These days non-xml vocabularies for modeling REST apis are more popular. > Each has its own strengths and weaknesses, depending on your needs. > I've ended up in very similar conclusion :-) I haven't heard about WADL yet, but right now I am investigating ways how to convert Swagger's OpenAPI (subset) to my DocBook structure. Jan - 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] REST API description
Dear All, is there any recommended DocBook tag set for describing REST API? My current structure is depicted in http://drifted.in/other/docbook/rest.png I use common elements like sections, simplesects, tables, programlistings, tips, but not sure what vocabulary use for URL fragments (1) or parameter descriptions (3, 4). (1) uri (2) synopsis (3, 4) informaltable I especially don't like (3, 4) as tables are quite heavy/complex objects for kind of variablelist with headers, which could be even auto-generated using localized resources. Any thoughts? Thanks, Jan - 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] xincludes and graphics
On 2017-11-23 Shikareva, Ekaterina wrote: > > I've encountered a known issue with including documents and images from > subdirectories into one main document for PDF output, and I can't wrap > my head around the solution. Can you please share some advice? > > Setup: > - Saxon 6.5.5 > - Xerces 2.11.0 > - docbook-xsl-ns 1.79.1 > > Folder structure: > doc/ > | > +-- main_file.xml > | > +-- doc1 > | | > | +-- figures/ > | +-- file1.xml > | > +-- doc2 > | | > | +-- figures/ > | +-- file2.xml > | > +-- doc3 > | | > | +-- figures/ > | +-- file3.xml > > Files in subdirectories are using images from the respective figures/ > folders with filerefs like fileref="figures/image001.png". > I suppose you are facing this old Xerces bug: https://issues.apache.org/jira/browse/XERCESJ-1102 You can either: 1. patch it for yourself or 2. generate outputs in two steps: a. use xmllint for resolving XIncludes into a single XML file (xmllint handles xml:base correctly) b. generate outputs using this single file More info about xmllint can be found at http://xmlsoft.org/xmllint.html It can be downloaded from http://xmlsoft.org/downloads.html For DocBook v5.0+ you can call it this way: xmllint --xinclude -o resolved.xml original.xml Regards, Jan - 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] [ANN] A new method for chunking HTML files
Dear All, if large XML documents are maintained, it is handy to split them into smaller parts (using XIncludes). Such content is not only easier to navigate but it also brings other benefits, especially if the source files are versioned using systems like SVN or Git. Unfortunately, there were no means to preserve this natural splitting when generating set of HTML pages. Good news. It is not a problem any more when keeping several simple rules and employing one handy open source tool. See further details on the blog http://www.doctribute.com/blog/ Any feedback is welcome, Thanks, Jan Tosovsky - 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] GitHub XSL issues
Dear All, I am facing issue already reported and even fixed via pull request, but it is still waiting for integrating. https://github.com/docbook/xslt10-stylesheets/issues/32 I've already fixed it for myself, but I have several related questions: (1) what is the official repository for XSL stylesheets - is it already GitHub or still SourceForge? (2) are GitHub 'Issues' a new official tracker for XSL issues? I am asking especially when seeing '0 closed' so far. (3) are pull requests appreciated contribution (seeing '14 open', some of them almost 1 year old) Thanks for clarification, Jan - 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] Pure JS WebHelp
On 2017-07-05 Wood Nick wrote: > > I followed your demo on the above subject through docbook-apps and was > really impressed with what you have done, there were some calls for you > to put your customization on GitHub, I know at the time you were busy, > have you been able to upload the stylesheets, if so, could you let me > know where to find them. I was busy with more urgent projects, but I believe in two weeks I could publish something. Btw, the original link is not available any more, that beta version is now in production: https://www.bilyujezd.cz/strucna-historie.html This site is not a typical use case, but it is something I can show to the public. Regards, Jan - 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] Pure JS WebHelp
Thank you all for your positive feedback! It is the best motivation for me. I am quite busy with other activities, but I'll try to move this further later next month. Some answers: > I notice you're using . Have you tried your XSL with > structuring? Sure, the section element is the first class citizen. > I'm especially interested to see if this could be adapted > to provide features (search, side navigation, etc) to > other tools that can only output HTML out of box. Not sure what is meant by other tools. To enable this functionality (using provided scripts) your HTML structure should match the original one (mine). Do those tools support generating outputs in a customized structure? > I'm curious on how you achieved not embedding ToC on every page. Indeed, there is no XInclude analogy in HTML :-( On top of that, you cannot access/manipulate local files via JavaScript (i.e. read HTML snippet in one file and put it into a dedicated DIV in your file). However, if your content is static and structured, it can be provided in the form of JavaScript object (JSON) and thus linked (e.g. in the HTML header) like other JavaScript files. Once loaded, that object is accessible like any other global variable. In my customization the nested object structure is iterated/converted into HTML's elements with proper CSS classes. The JSON is same for all pages. The current menu item is highlighted dynamically via script. In one huge document (2000 PDF pages) the embedded ToC itself represented ca 2 MB! In every page. The rest of file size was between 10-600 kB, the total package size was ca 150 MB. Loading pages was so sloow. While the browser has to load the similar size now (just split into two parts), it is much faster as that separate ToC (JSON) can be cached and reused for other pages. Jan - 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] Pure JS WebHelp
Dear All, as promised, I've published a demo output https://www.bilyujezd.cz/beta/strucna-historie.html Core changes against the current WebHelp: - responsive design (Mobile First) - breadcrumb - improved ToC processing (ToC is linked, not embedded in every HTML file) - enhanced search related code (cleaning up the code for better maintenance) - enhanced translation support (all messages are stored in standard l10n XML files) - storing client state even on file system or localhost (utilizing HTML5 Local Storage) - removing jQuery and jQueryUI dependency Further features: - ability to enlarge downsized images (aka lightbox, especially useful for SVG images) - ability to copy links to specific anchors - SASS styling (interpreted into CSS) Weaknesses: - only modern browsers are supported (Chrome, FF, Edge, IE10+) - no custom params to override current bahavior - no out-of-the-box scripts for copying dependencies to the target destination Should I put related XSL files and resources to my GitHub account or directly to some DocBook sandbox? Thanks, Jan - 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] webhelp jquery update
On 2017-04-03 Katharina Udemadu wrote: > > has anyone updated the jquery files included in the webhelp template to > a later version? In my customization I even get rid of entire jQuery stuff in favor of pure JS :-) My original plans were to offer this back to the community, but with implementing more and more features this has become quite complex. I'll try to produce a sample output and make it public later next week. Then we will see if there is enough interest so investing time into it (especially documentation) pays off. Regards, Jan - 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] Reset footnote numbering for each chunk
On 2017-03-08 Jan Tosovsky wrote: > > my HTML output consists of (manually) chunked chapters and sections. > However, my footnotes are still numbered from the beginning. > > I've located the following template in the html/footnote.xsl: > > > > which implements quite basic counting (simplified here for better > understanding): > > > > Is there a simple way to get actual chunk element inside this template > and modify the above code to select just 'preceding::footnote' up to > that chunk element? > Once asked another idea came to my mind. And it seems to be a viable approach... (1) Using this code I can get unique ID of chunking element: generate-id(/*[1]) (2) In the template I use the above code this way: TODO: (a) This is simplified demonstration without excluding table footnotes. (b) That XPath //*[generate-id(.) = $currentChunkElementId] is quite inefficient and there is mostly likely room for other improvements. It would be nice to have this numbering system driven by a new HTML parameter ;-) Thanks, Jan - 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] Reset footnote numbering for each chunk
Dear All, my HTML output consists of (manually) chunked chapters and sections. However, my footnotes are still numbered from the beginning. I've located the following template in the html/footnote.xsl: which implements quite basic counting (simplified here for better understanding): Is there a simple way to get actual chunk element inside this template and modify the above code to select just 'preceding::footnote' up to that chunk element? Thanks, Jan - 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] WebHelp search - anybody working on improving?
On 2016-11-10 Janice Manwiller wrote: > > The WebHelp search is a source of frustration, mostly because it does > not support phrase searches... > > Has there been any effort to improve the search? Has anyone else > implemented a custom search that supports phrase searches? > In the current implementation there is no way to do it. When search index is built, the original content is split into words, from which kind of look-up table is created (which word in which file is present). When search phrase is entered, it is again split into separate words and each of them is searched in that look-up table. The result is the number of occurrences of the given word in the particual file, which is used for ordering the search results. In case of phrase searches the search index would have to store the full content. When performing the search all those content snippets would have to be processed using more complex algorithms. But instead of reinventing the wheel I believe there are some lightweight JavaScript ports of Lucene engine, which could be somehow integrated. However, I am not expert in this field. Jan - 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] [OT][XSLHL] Support for Objective-C
Dear All, I have slightly off topic question. Has anybody implemented code highlighter for Objective-C? I am trying to create it, but I need more complex logic for processing directives. I am missing highlighter options documentation. There seems to be a dedicated page on the wiki, but I have no sufficient permissions: https://sourceforge.net/p/xslthl/wiki/Syntax%20Highlighter%20Options Error 403 Create access required Btw, how about migrating this project to GitHub? Jan - 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] [WebHelp] Language support for search
Dear All, looking into the language support I can see only en/es/jp stopwords and de/en/fr stemmers: http://snapshots.docbook.org/xsl/webhelp/template/search/ Has anybody implemented additional ones? In foreseeable future I'd like to cover also pt/it/cs/nl. I have some ideas, based on lucene analyzers, but why not use something existing ;-) Thanks, Jan - 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 to ConTeXt XSL stylesheets
Dear All, let me introduce a new project aiming to offer outstanding typography for your PDF outputs from DocBook XML source. Details can be found at http://doctribute.com/blog/ There is also a step by step description how to test stylesheets on a sample DocBook book. Let's give it a try! If you encounter any misleading info or inclarity, let me know. Thanks, Jan - 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] [OT] DocBook XSL license
Dear Richard, On 2016-03-16 Richard Hamilton wrote: > On 2016-03-12 Jan Tosovsky wrote: > > > > I am implementing stylesheets for DocBook conversion into special > > format which I'd like to publish on GitHub. I am reusing the code > > from DocBook XSL distribution - from /common and /lib. > > > > I plan to distribute it under a common license, most likely GPL v3. > > I'd like to verify if this license is compatible with that found in > > DocBook XSL distribution > > We agreed to change the license file to identify the license as the MIT > license, then separately note the additional restriction concerning the > use of the names of the copyright holders. > thanks for moving this further. I am just worried mentioning MIT with those additional restrictions might cause more confusions than today. Seeing MIT one expects something. I would rephrase [1] - If You Change MIT, It's Not MIT Anymore ;-) While it is completely up to the author, I'd either switch to common license without extra claims, or use specific one as currently. Anyway, I changed my mind and for my purpose I'll use the same license as that used in DocBook XSL distribution. I'll sync the former if the latter changes in any way. Jan _ [1] http://www.oreilly.com/openbook/docbook/book/ch05.html - 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] [OT] DocBook XSL license
Dear All, I am implementing stylesheets for DocBook conversion into special format which I'd like to publish on GitHub. I am reusing the code from DocBook XSL distribution - from /common and /lib. I plan to distribute it under a common license, most likely GPL v3. I'd like to verify if this license is compatible with that found in DocBook XSL distribution: http://docbook.sourceforge.net/release/xsl/current/COPYING or alternatively http://docbook.sourceforge.net/release/xsl/current/doc/copyright.html What do you think? Btw, do you happen plan changing this license to something more common? :-) Thanks, Jan - 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] Madcap Flare to Docbook conversion
On 2015-12-09 Frank Arensmeier wrote: > On 2015-12-09 Peter Lavin wrote: > > On 2015-12-09 Frank Arensmeier wrote: > > > > > > I am wondering, does anyone have any experience with transforming > > > Madcap Flare to Docbook? > > > > Do you have access to Flare HTML output files? If so, use these > > files rather than the "raw" Flare files. The raw files will > > probably contain proprietary tags > > I was hoping for someone who already has done something similar before > and who could share some insights. > It resembles my situation some time ago when incorporating (external) Author-it documentation into our Docbook based workflow. Although it is presented as single source tool with ability to 'export' XML file, this XML is rather a database dump of various tables with complex relationships, which turned out to be too complex for converting into a typical document structure. We finally decided to migrate those documents manually (copy & paste). Most of them were later refactored anyway to match our writing style/rules. But it depends on the ammount... Btw, what is the reason to abandon Flare in favor of Docbook? Regards, Jan - 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 Wiki
Dear All, recent discussion touched various parts of DocBook workflow. In my opinion it could be helpful to convert some ideas into dedicated wiki articles or update current ones. http://wiki.docbook.org/ I've tried to create a new account, but I got an error related to 'newaccount' action. Is the access somehow limited or there is some problem with the engine itself? Thanks, Jan Btw, how about running it on https or switching to mediawiki? - 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] DB2PDF et al. alternative (long). Was: Show off what you've done with Docbook
Dear Giuseppe, thanks a lot for this valuable post! On 2015-09-15 Giuseppe Bonelli wrote: > > My conclusion is that while DB is *very* good and well supported as a > structuring and archiving format, FOP and friends are not a suitable > solution for producing professional PDF. > ... > I then started using a DB/latex/pdf toolchain, but I usually find this > solution not flexible enough (having to edit some code just to move a > figure is not something that scales up that well) and I think that the > batch pagination paradigm used by tex/fop is not suitable for complex > books. It depends ;-) In certain cases you can't really avoid orphan/widows or too much space left on the bottom of the page as the content riddled with keep-with rules doesn't fit, etc. I like typography, good looking outputs, but from my experience almost nobody cares. And there is no ROI to tweak the output to meet all the rules, especially in software documentation I am experienced with. If automation is combined with manual steps, it isn't 'single source' any more. The same steps have to be done with every regenerating, which may become a tedious task. And if the content is provided in multiple languages, any manual interventions are even harder. > I now routinely use with great satisfaction and efficiency a workflow > based on transforming via xslt pipelines from docbook to idml (the xml > format used by Adobe indesign) and then producing typographically > perfect PDF interactively from the automatically generated indesign > files. I've tried something similar in the past, but I found some limitations in InDesign which discouraged me from moving this forward. > For going from xml to indesign (idml) all you need is an indesign > template with the layout and the typography (note that the indesign > template could be created and maintained by a graphic designer who > knows absolutely nothing about tags or xml/html/Idml) and a mapping > xml configuration file. Tables, images and math formulae are > supported almost out of the box. My problems were footnotes, used frequently in my publication. I couldn't find any syntax for them in IDML. I then investigated various batch-paginating engines. You can find a brief comparison here: http://drifted.in/publishing/publishing-typografic-quality-of-dynamically-ge nerated-pdf-outputs-en.html This finally led me to investigate db -> ConTeXt (luaTeX) -> PDF route (forking outdated dbcontext), which was tough (lost in macro soup), but I was really pleased with the result. This was rather text-oriented content with various styles, but minimum graphics. For the rest (with advanced styling) I still use XLS-FO, because: * templates are already customized * there is no ROI to switch to another workflow just for the curiosity * there is risk not all features are available (I do some post-processing using an intermediate format) Jan <> - 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] Show off what you've done with Docbook
On 2015-09-13 Warren Block wrote: > On Sun, 13 Sep 2015, Gerard Nicol wrote: > > > Does anybody sell a commercial Docbook customization layer? > > I don't know of any, but would be interested. Maybe there is a place > with downloadable DocBook "themes", or maybe it is time for that. There are two problems here: (1) Outputs should usually meet corporate identity (you cannot just pick a stock theme) (2) Majority of end-users use just subset of elements (and there is no point in styling the rest) I implemented 6 complex customizations in the past (each consisting of 3+ formats, usually PDF, WebHelp, CHM). Two of them are retired now. They could be shared after removing sensitive info, but two aforementioned problems make me quite skeptic of their usefulness for someone else... Jan <> - 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] PDF-like HTML output
On 2015-08-24 Carlos Araya wrote: On 2015-08-19 Jan Tosovsky wrote: On 2015-08-19 Carlos Araya wrote: The main issue for me is that, to my knowledge, there is no open source solution that works with CSS Paged media and its associated generated content) and none of the available commercial solutions is cheap. I personally take those HTML+CSS processors as temporary 'dead end' solution which will be (in long term) replaced with regular web browsers. The purpose of Paged Media is to generate print-ready layouts... there are books that have been created with CSS Paged Media ... I would not call it a dead end solution just yet. By that 'dead end' I meant rendering outputs by dedicated (commercial) processors (in a long term). So I was quite skeptic to CSS paged media (not mature yet, expensive processors) ... until I met vivliostyle.js. Thank you for sharing this. I think it's worth taking a look at it but I'd ask right off the bat what's the browser support for this technology and what happens when Javascript is not available or we need it to work with assistive technology? Basically, Javascript emulates functionality not implemented in browsers yet. As browsers will become more mature, the need for such a 'patching' library will decrease. (We can see similar decline of jQuery library that 'patched' various browser incompatibilities). But the coverage of vivliostyle is not yet very clear to me (what gaps does it really fill). If Javascript is disabled, a browser will render elements incorrectly. It is up to the end user :-) That said there's nothing stopping you from hacking Norm's XSLT 2 stylesheets (https://github.com/docbook/xslt20-stylesheets) to generate the HTML you need to work with vivliostyle :) Yes, I am just gathering some feedback if something like this is worth investing time. Once your content is rendered in a browser, it is quite straight forward to convert it into PDF. But to be honest, this conversion IMHO doesn't make much sense any more ;-) Why do you see it making no sense? Modern browsers read PDFs natively and render the content on canvas using JavaScript. So in my opinion it is better to skip that HTML+CSS - PDF and PDF - 'canvas' conversions by providing the content directly in browser's natural format. I would also like the capability to share the content and the annotations I make without violating the license to my content. hmm, a good point. IF you're interested on the convergence between web, ebook and other digital content you may want to check the epub+web white paper at: https://w3c.github.io/epubweb/ thanks for the link, a nice overview. Jan attachment: winmail.dat - 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] PDF-like HTML output
Dear Carlos, thanks for your valuable feedback! On 2015-08-19 Carlos Araya wrote: The main issue for me is that, to my knowledge, there is no open source solution that works with CSS Paged media and its associated generated content) and none of the available commercial solutions is cheap. I personally take those HTML+CSS processors as temporary 'dead end' solution which will be (in long term) replaced with regular web browsers. So I was quite skeptic to CSS paged media (not mature yet, expensive processors) ... until I met vivliostyle.js. It brings CSS paged media to browsers NOW. To some extent it makes dedicated processors redundant. I don't believe all works in reality as smooth as announced on their page, but I like the concept. As it is open source, you can extend it if you find some funcionality missing. So instead of patching XSL-FO processors I'd rather patched this Javascript library (if I could). It is also temporary 'dead end' which will be replaced with regular browsers, but you can prepare the content in pure CSS standard NOW with minimal risk of further updates when browsers will become mature enough. Once your content is rendered in a browser, it is quite straight forward to convert it into PDF. But to be honest, this conversion IMHO doesn't make much sense any more ;-) All above shouldn't be taken too seriously. It is just my (naive) view. The final question I'd have before jumping into CSS Paged Media development is for what version of the stylesheets? While I'd prefer XSLT2, I am afraid this is not acceptable by majority of end users. Jan attachment: winmail.dat - 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] PDF-like HTML output
Dear All, (1) there was lot of work in W3 recently dedicated in CSS for paged media (2) there are conversion tools from HTML+CSS to PDF utilizing these features (3) some interesting JavaScript libraries have appeared (e.g. vivliostyle.js) emulating the intended rendering to 'yet inmature' browsers (polyfills) which make me wonder if there is an interest in making some kind of reference implementation of PDF-like output in HTML+CSS from DocBook source, especially for (3). Has anybody any experience with it? I am not experienced in this field, but I am willing to help, at least with testing :-) Thanks, Jan attachment: winmail.dat - 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] Visual DocBook editors
Hi George, On 2015-05-24 George Bina wrote: On 23/05/15 00:37, Jan Tosovsky wrote: originally I've been searching for any free / low cost visual docbook editor for rare use by various non-techie people within company as full-featured product (e.g. Oxygen Author) seems to be an overkill. Re oXygen XML Author: for this rare usage we provide floating licenses - one such license may be enough for all users within your company. Wow, I wasn't aware of this option, this is indeed a way to go! On the web, we have available a test deployment of the oXygen Webapp at https://www.oxygenxml.com/webapp-demo-aws/ Glad to see Oxygen's following the trends. Btw, is there any place for providing the feedback? Thanks, Jan - 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] Visual DocBook editors
On 2015-05-23 Simon Dew wrote: On 2015-05-22 Jan Tosovsky wrote: originally I've been searching for any free / low cost visual docbook editor for rare use by various non-techie people within company as full-featured product (e.g. Oxygen Author) seems to be an overkill. Unfortunately, there are just several alternatives, none of them below $50. The free (GPL) version of Serna 4.4 is still available: http://sourceforge.net/projects/sernafree/ A little old now, but might be worth evaluating. I remember this product. I've tried to find it recently, but I was redirected a completely different product, not free any more. Thanks for your link. I've tried it now, but Serna has two main drawbacks from my POV: * it is a 'dead' project * you cannot switch to the raw XML version and do some interventions On top of that, editing of attributes is not very user friendly. Additionally, attributes cannot be displayed directly in tags (if they are enabled in the visual mode). I stopped investigate it further as even these limitations are blockers for me. Jan - 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] Visual DocBook editors
Hi Nils, wow, what a nice list of projects! On 2015-05-23 Nils Cordes wrote: On 2015-05-23 Jan Tosowsky wrote: Have I overlooked any handy tool or service? NeoDoc Calenco http://www.neodoc.biz/en/calenco/index.html http://sourceforge.net/projects/calenco/ I can see just marketing on their site, not a live demo or even screenshot of their content editor. DocBook is not mentioned anywhere... Has anybody any experience with this system? Doctored.js http://holloway.co.nz/doctored/ https://github.com/holloway/doctored While not a real WYSIWYG this one looks cool. But understaffed (maintained by a single person... no recent updates...). Some operations seem to be overcomplicated (how do I delete a tag without switching into source XML?). JBoss Tools Visual Editor http://tools.jboss.org/ https://github.com/jbosstools/jbosstools- vpe/tree/master/plugins/org.jbo ss.tools.vpe.docbook Is there any screencast to demostrate how it works? DEP4E http://dep4e.sourceforge.net/ http://sourceforge.net/projects/dep4e/ In the quick start guide there is only raw XML editing mentioned, not WYSIWYG. Regards, Jan - 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] Visual DocBook editors
Dear All, originally I've been searching for any free / low cost visual docbook editor for rare use by various non-techie people within company as full-featured product (e.g. Oxygen Author) seems to be an overkill. Unfortunately, there are just several alternatives, none of them below $50. Sadly, DocBook doesn't seem to be offered as online tool for interactive/collaborative editing in the cloud either. For e.g. LaTeX there are nice apps: https://www.overleaf.com/ https://www.authorea.com/ https://www.sharelatex.com/ Have I overlooked any handy tool or service? Please share. Thanks, Jan attachment: winmail.dat - 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] [XSL-FO] CALS table width issue for columns without colwidth
Dear All, I've migrated some old customization layer and found it behaves differently for certain tables. When no colwidths are specified, I expect all columns occupy just required width (as in case of HTML tables). But in 1.78.1 such a table is stretched to the all available width and columns are distributed evenly (XEP). It looks ugly especially if you have few narrow columns. Using a diff tool I found it is caused by removing the condition mentioned in this thread: https://lists.oasis-open.org/archives/docbook-apps/201005/msg00061.html I fixed it (inserted that condition back) in my customization layer, it work as expected, but it would be nice to fix/improve the trunk code as well. Or is it rather XEP bug which doesn't follow specification and renders tables incorrectly? Thanks, Jan attachment: winmail.dat - 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] Solution: Page numbers not aligned in TOC
On 2015-04-09 Martin Doucha wrote: On 2015-04-09 Kallauch Benjamin wrote: I noticed a fuzzy looking TOC some time ago with my FO-results from FOP 1.1 and DocBook-XSL 1.78.1. The page numbers seemed to be misaligned slightly. They ought to be aligned on the right side, but they were not. The reason for that lies in the toc.line named template in fo/autotoc.xsl. Between the dotted line there is a leading and trailing space: xsl:text /xsl:text. At least this causes FOP (maybe in combination with only some font types and sizes) to render misaligned page numbers. A good catch! Thanks for sharing. But keep in mind not all fonts have #x2004 code point in their character set. It's a bug in FOP. I've reported it some time ago and made a patch for SVN version of FOP. You can find the specific conditions which trigger the bug in my bugreport: https://issues.apache.org/jira/browse/FOP-2438 See also https://issues.apache.org/jira/browse/FOP-1444 Jan attachment: winmail.dat - 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] Non translatable content in Docbook 4.x
Dear All, I'd like to mark some text as non translatable. I could add a common attribute to all elements in original DTDs, but I like the idea of utilizing ITS standard for this purpose, which seems to be supported in CAT tools. I've found this explanatory article, but I'd like to use it in old 4.x DTD. http://xmlguru.cz/2013/05/docbook-and-its2 Is there any way? Some extension like for xi:includes ? Btw, there is no ROI to switch to Docbook 5. Thanks, Jan - 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] [WebHelp] Incorrect initial scroll to anchor in Chrome
On 2014-10-29 Jirka Kosek wrote:
On 27.10.2014 19:04, Jan Tosovsky wrote:
This seems to be caused by the following script located in the
main.js file:
var hash = window.location.hash;
if (hash) {
var targetOffset = $(hash).offset().top - 120;
$('html,body').animate({scrollTop: targetOffset}, 200);
return false;
}
Could you try replacing $('html,body') with $('#content'). I recall
that there were some problems related to former selector, but I'm not sure
whether this will help here.
Thanks for the hint. This approach would be much easier, but it unfortunately
doesn't help.
In meantime I discovered it works fine for files browsed from local disk, but
fails when files are located on a local network or Internet. So I suppose it is
somehow related to security.
I've tried to create a minimal example, but I reduced it too much so it is
working. I am going to do a better job ;-)
Regards, Jan
-
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] [WebHelp] Incorrect initial scroll to anchor in Chrome
Dear All,
I've noticed incorrect scrolling the page in Chrome when the URL contains a
hash character.
This seems to be caused by the following script located in the main.js file:
var hash = window.location.hash;
if (hash) {
var targetOffset = $(hash).offset().top - 120;
$('html,body').animate({scrollTop: targetOffset}, 200);
return false;
}
While target offset is -195 in FF, it is 2200 in Chrome. The required anchor
is not scrolled precisely to its location, but ca 300 px towards the bottom.
However, on page reload it is sometimes correct, sometimes more or less than
the initial value. This inconsistency is really weird.
I've found several threads mentioning incorrect Chrome behaviour when
determining offset top value on StackOverflow, but it is not very clear to
me if this is our case.
Has anybody any experience with this or fix?
Thanks, Jan
-
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] adding customization layers to Oxygen XML author
On 2014-03-28 Carlos Araya wrote: I've downloaded XML author and after looking at resources I'm drawing a blank as to how to add my customization layers to the editor's workflow. Does anyone have a guide or can point me to resources to get this accomplished? All Docbook related stuff is stored in the Frameworkd folder in the Oxygen installation directory. Browsing this content you'll get a rought idea what can be changed. You can place there your document templates, stylesheetes, customized DTDs, customized CSS for displaying the content when editing, customized toolbars, context menus etc. A good starting point is e.g. here: http://oxygenxml.com/doc/ug-author/#topics/author-docbook4-doc-type.html hth, Jan - 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] performance issue - 5MB Source lead to a processtime up to 20 minutes
On 2014-01-16 Jirka Kosek wrote: On 16.1.2014 17:32, markus.sticker.e...@zf.com wrote: If removed some obsolate (for my case) Parts and now I'm using the saxon 9.5 with multithreading and 3G heap so my process time is about 3-5 minutes. Not good - just a little better. First, I would check that you are using recent DocBook XSL stylesheet distribution (1.78.1). Then you can run Saxon with -t switch which will show you how long resources are loaded and transformed. This can give you some insight. Multi-core processor will not help, unless you are using features from commercial version Saxon-EE (and those features are not used in DocBook stylesheets), transformation runs in a single thread. Have you set up catalogs in either xslproc or saxon? Otherwise DTDs are downloaded from the web which is much slower. IIRC, in a draft mode some resources are also taken from an external URL. You can simply test this with disconnected network ;-) Jan PS: In 20 minutes it is possible to process 2500 pages PDF manual even without a special HW (I mean XML-FO-PDF). - 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: Syntax highlighting
On 2013-12-09 Norman Walsh wrote: ... future work on XSL FO has largely been abandoned. Does it mean that XSL-FO 2.0/next is not planned any more? Is there any citation for this? Thanks, Jan - 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
On 2013-12-06 Norman Walsh wrote: I'm also tempted to abandon the XSL stylesheets and work instead on a purpose-built HTML+CSS rendering for printing. While I don't plan to upgrade my generating workflow to XSL 2.0 stylesheets in the near future, I am quite curious whether the proposed HTML+CSS approach can really cover all common needs: 1. ToC and Index with page numbers 2. Bookmarks 3. Double-sided version (different recto/verso margins, header/footer content) 4. Running header-footers (differences amongst title, blank or recto/verso pages) 5. Absolute positioning of title page graphics or other page elements 6. Using PDF format for images 7. Change bars Currently I also post-process final PDF files utilizing an intermediate format (I can retrieve the page # and Y coord for the specific ID in this format). Thanks, Jan - 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] HTML5 Audio + Video multiple sources
On 2013-12-08 Bob Stayton wrote: On 12/7/2013 12:27 PM, Peter Fleck wrote: 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 This is not yet supported in the stylesheets. ... 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. It relates to alternating raster/vector images used in my documents. Currently I specify just 'image.png' in the DocBook source. It is used 'as is' in HTML outputs, but for PDF outputs my custom XSLT function looks for 'image.pdf' and if it exists, it is referenced instead in the final FO source. It could be used as a temporary solution also in your case. Regards, Jan - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
