Re: [docbook-apps] Webhelp: My adventures therein

[Sebastian Holder]

Hi Mary, hi all,

under 
https://sourceforge.net/p/docbook/bugs/1390/
I have created a bug report (including one possible solution) for the issue 
with links to local (within-page) IDs. (see quote below)

Best regards,
Sebastian Holder


-- 
levigo solutions gmbh - ein unternehmen der levigo gruppe
Bebelsbergstraße 31 Telefon: 07031 / 4161-20
D-71088 Holzgerlingen   Telefax: 07031 / 4161-21
GF: Jürgen Maestling, Jörg Hennehttp://solutions.levigo.de/
Registergericht: Stuttgart HRB 245 178  USt-ID: DE216017084
-


> -Ursprüngliche Nachricht-
> Von: Mary Tabasko [mailto:taba...@telerama.com]
> Gesendet: Dienstag, 9. September 2014 02:45
> An: docbook-apps@lists.oasis-open.org
> Betreff: [docbook-apps] Webhelp: My adventures therein
> 
> Hi, all.
> 
> 
> Issues with links to local (within-page) IDs.
> 
>   We noted that within-page links did not work. We found the
>   messages on the docbook-apps list about this, and tried
>   commenting out the salient block in the "main.js" file. This
>   fixed the problem for most links within a page (those within "content".
>   (We tried using the fix in the later snapshot, but we didn't see any
>   difference.)
> 
>   We also noted another problem with generated links from the sidebar TOC.
>   If you were on a page like, say, "bk01.html" and tried to navigate
>   to "bk02ch01s04#id-4.1.3.4.6" (a totally made-up id value, but
>   the format is what we got), the correct page and local link would load
>   (that is, the new page would be scrolled to the local link), but the
>   sidebar disappeared, and the sidebar toggle would not bring it back.
> 
>   (Clicking the Next link followed by the Previous link would restore
>   it, but the direct navigation from the sidebar TOC always clobbered the
>   sidebar.)
> 
>   The problem only occurred with generated IDs. Navigating from the
>   sidebar TOC on "bk01.html" to "bk02ch01s04#using-passwords" worked
>   fine. Looking at the gross structure of the links in the sidebar
>   TOC revealed no differences. The difference had to be in the structure
>   of the values of the IDs.
> 
>   By default, the "object.id" template with "generate.consistent.ids"
>   set makes values like "id-4.2.6.3". I played around with these values
>   a bit and determined that changing the "dots" to "dashes" solved the
>   problem. That is, links with id values like "id-4-2-6-3" worked just
>   fine. (The original ids work fine within the content block; it's only
>   using them from the sidebar TOC that causes the problem.
> 
>   I could find no way to tell the "generate-id" function to alter this
>   structure, so I had to override "object.id" and do it myself. (The
>   problem appears to be in some piece of JavaScript, but I have not
>   attempted to find it. The browser follows the links fine.)
> 
>   For completeness, I put "." characters into a couple of our explicitly
>   provided IDs and the links to them. They then exhibit the same problem:
>   the sidebar does not appear when you traverse to such an ID. (This
>   was not a browser-specific problem, either.)
> 
>   Note: Unless you have "." in your explicit IDs or have set
>   "generate.consistent.ids" for some other reason, this issue wouldn't
> affect
>   anyone who didn't generate the sidebar TOC separately like we did.
> 


-
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] Automatically detecting which PDFs are affected by changes in a DocBook Git commit

[Camille Bégnis]

Hello,

we have implemented in the Calenco CMS a method based on the IF FOP
intermediary XML Format, which is an XML description of each resulting
page. It is based on the following simple algorithm:

1. Generate the original document IF XML
2. Generate the IF XML based on new sources
3. Compare with an XSLT the 2 IF documents to extract whatever
information we need

We have been using this successfully in production to generate PDF with
only the modified pages between 2 different versions of a document.

HTH,


NeoDoc
NeoDoc
Camille Bégnis
Gérant
cami...@neodoc.fr
Tél: 04.42.52.24.20
http://www.neodoc.fr/
789, rue de la gare
F-13770 Venelles
qrcode
Le 01/11/2016 à 15:42, Bergfrid Skaara a écrit :
> I´d like to know the overall difference between versions X and Y of a
> single PDF - automatically so we don't need to inspect and compare
> page by page manually (simplifying release process).
>
> I need to know all PDFs (and what content within them) that have
> changed as a result of commits X,Y, Z (simplifying review and release
> process).
>
> I´d like notifications if a commit targeted only at feature A ends up
> changing PDFs unrelated to feature A. This would typically indicate
> profiling errors or misplaced includes that need to be fixed.
>
> Inserting build numbers or some similar ID from the CI environment
> into the PDF metadata would also help.
>
> The challenge with comparing PDFs is all the noice you get from layout
> changes (white space) and info in headers and footers such as dates
> and version numbers.
>
> And if you go the convert-PDFto-text-before compare route, would it
> not be better to compare the intermediate FO files rather than waste
> time going through the entire publishing pipeline first?
>
> We are not looking to replace our current CI environment. Extending
> the current build-logic is not a problem, but I´m not sure what the
> new logic should look like.
>
> Bergfrid Skaara Dias
>
> On Wed, Oct 26, 2016 at 6:48 PM, Stefan Seefeld  > wrote:
>
> On 26.10.2016 11:04, Bergfrid Skaara wrote:
> > Hi,
> >
> > We use Git to version control our modular DocBook XML code base. I´d
> > like to enforce stricter change management than what simply
> inspecting
> > the Git log manually offers. Specifically, I want to trace each
> > modular DocBook XML fie that has been changed up to the PDFs
> that will
> > be changed as a result.
> >
> > Tracing the ancestor files through a sequence of xi:includes is
> > trivial. My challenges are:
> >
> > 1. Profiling. I need to trace ancestor elements taking profiling
> into
> > consideration.
> > 2. Entities. We use entities extensively for both aliases and reused
> > text. Is there a way to track effects of changed entities without
> > starting with a brute force search of all DocBook XML files
> using that
> > entity?
> >
> > Are there any tools, standalone or add-ons to oXygen, that support
> > this or similar behavior, or am I better off writing my own
> script? In
> > case of script, which option is better: XSLT or any scripting
> language
> > facilitating text parsing?
>
> I'm not quite sure what you mean by "change management", and what
> it is
> that you want to enforce, and neither what exactly you want to trace.
>
> Generating a PDF from XML sources typically requires some build logic,
> so I think the best you can do is use that very build logic and then
> compare (or validate) the generated PDF (or any intermediate formats,
> such as FO). That can easily be done in a CI environment (such as
> Travis-CI), so you can fully automate that such that the same
> process is
> executed for each push.
>
> Stefan
>
> --
>
>   ...ich hab' noch einen Koffer in Berlin...
>
>
> -
> To unsubscribe, e-mail:
> docbook-apps-unsubscr...@lists.oasis-open.org
> 
> For additional commands, e-mail:
> docbook-apps-h...@lists.oasis-open.org
> 
>
>