Date   

Re: PDF production with SVG having hot spots

Dan Caprioara
 

If you can switch from XSL-FO to CSS, please note that Oxygen XML Editor includes a DITA-OT plugin that outputs PDF based on a CSS customization (not XSL-FO) and it supports image map rendering and links in SVG images:

https://www.oxygenxml.com/doc/ug-ope/topics/dcpp_images.html#dcpp_how_to_use_image_maps

Many regards,

Dan

On 1/25/2021 1:28 PM, Pierre Attar wrote:
Hi,

I have a technical documentation with a lot of SVG files having hot spots.
Hotspots are managed using a javascript function call on g/@onmouseover attributes.
The function itself changes some opacity attributes of the graphic.
The HTML production works fine and all hotspots are active.

Using the same SVG, with the standard DITA-OT PDF (XSL-FO) plugin, the hotspots are no more active and all images are flats.

So, does someone foud a solution, a workaround, for keeping these kind SVG hotspots actives ?
Is there an other way to code SVG for being able to make them interactive both on PDF and HTML ?

Thanks for sharing any idea, solution,

Pierre





Re: Allow variables to be referenced from @scope="peer" maps

ekimber@contrext.com
 

This is an example of where a local, targeted solution is relatively easy (just a bit of preprocessing or relying on knowledge of cases that won't occur in your content) but the general solution would be hard (because it has to handle all cases, perform well, be extensible, report exception conditions clearly, etc.).

It's not hard to implement simple processes that operate on maps and do specific things, either using the output of the OT preprocessing stage or just operating on the maps directly if you know you don't need to worry about stuff like filtering, metadata propagation, etc.

The DITA Community utilities area on github has general XSLT scripts for operating on maps, including resolving key references and resolving topicrefs to topics. With that code as a base it should be as easy as it can be to extract topic titles or book titles. https://github.com/dita-community/dita-utilities/tree/master/src/xslt

Then, as you say, it's a matter of optimizing performance: do you do the processing every time or cache results? If you cache results, how do you keep the cache up to date?

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 1/25/21, 8:06 AM, "Chris Papademetrious" <main@dita-users.groups.io on behalf of chrispitude@gmail.com> wrote:

Hi Eliot, David,

Thanks to both of you for sharing your thoughts!

Some background information... We use cross-book links in our content. On the authoring side, we have a compiled Perl script (accessible as an external tool in Oxygen) that populates cross-book link target text in the DITA source files. On the production side, we use a variant of the following plugin to late-resolve links in the final HTML output:

https://github.com/chrispy-snps/DITA-fix-xbook-html-links

Thus, many of our books already reference other books as peer maps.

A writer asked me how to get the title of a referenced book so she could get the title of a peer-referenced book, something like this:

<p>See <ph keyref="bookB.BookTitle"/> for more information.</p>

I thought it would be neat to define a BookTitle variable in every book, even using its value as the <bookmap> title so the title is single-sourced everywhere from the variable. Clever me! But this is when I found out that variables in peer maps are not accessible.

Could I solve this by defining every book title in a shared "booktitles" map, then referencing that map from every book? Well sure I guess, but yuck. Every book has a title, I just want to get to it.

Right now DITA offers


* @scope="peer" maprefs (ignores map+topic content)
* @scope="local" maprefs (processes map+topic content)


Functionally, I want something between these. I want to process a peer book's map structure but not its topic content, with the exception of preserving topic <title> elements to enable processing to populate cross-book link target text.

This would elegantly solve some challenges we have with cross-book links to topics with conditional-content titles, as then the DITA-OT profiling behaviors simply play out in the peer maps and resolve the content for us. Currently our Perl script flags these for human intervention. It would also avoid issues with stale target text because the target topic title changed but the referencing-topic writer didn't know to rerun the Perl script.

Would this increase processing time? Sure, but I'd gladly exchange that for the flow simplification. And if I can figure out how to ignore <body> elements during peer-map topic read-in, the vast bulk of the peer map content would never even make it into memory; we'd basically just have skeleton peer maps available to resolve references, and the processing overhead should be minimal.

I'm going to try hacking my way through this to see how far I get. I will definitely follow up here with my progress, and I will likely follow up with questions. :)

- Chris


Re: Allow variables to be referenced from @scope="peer" maps

Chris Papademetrious
 

Hi Eliot, David,

Thanks to both of you for sharing your thoughts!

Some background information... We use cross-book links in our content. On the authoring side, we have a compiled Perl script (accessible as an external tool in Oxygen) that populates cross-book link target text in the DITA source files. On the production side, we use a variant of the following plugin to late-resolve links in the final HTML output:

https://github.com/chrispy-snps/DITA-fix-xbook-html-links

Thus, many of our books already reference other books as peer maps.

A writer asked me how to get the title of a referenced book so she could get the title of a peer-referenced book, something like this:

<p>See <ph keyref="bookB.BookTitle"/> for more information.</p>

I thought it would be neat to define a BookTitle variable in every book, even using its value as the <bookmap> title so the title is single-sourced everywhere from the variable. Clever me! But this is when I found out that variables in peer maps are not accessible.

Could I solve this by defining every book title in a shared "booktitles" map, then referencing that map from every book? Well sure I guess, but yuck. Every book has a title, I just want to get to it.

Right now DITA offers

  • @scope="peer" maprefs (ignores map+topic content)
  • @scope="local" maprefs (processes map+topic content)

Functionally, I want something between these. I want to process a peer book's map structure but not its topic content, with the exception of preserving topic <title> elements to enable processing to populate cross-book link target text.

This would elegantly solve some challenges we have with cross-book links to topics with conditional-content titles, as then the DITA-OT profiling behaviors simply play out in the peer maps and resolve the content for us. Currently our Perl script flags these for human intervention. It would also avoid issues with stale target text because the target topic title changed but the referencing-topic writer didn't know to rerun the Perl script.

Would this increase processing time? Sure, but I'd gladly exchange that for the flow simplification. And if I can figure out how to ignore <body> elements during peer-map topic read-in, the vast bulk of the peer map content would never even make it into memory; we'd basically just have skeleton peer maps available to resolve references, and the processing overhead should be minimal.

I'm going to try hacking my way through this to see how far I get. I will definitely follow up here with my progress, and I will likely follow up with questions. :)

 - Chris


Re: PDF production with SVG having hot spots

Radu Coravu
 

Hi Pierre,

I also don't think there is a way to have the PDF interpret Javascript code inside SVG images.
Maybe you can pre-process the SVG images at publishing time and convert the Javascript code to actual svg circle or rectangle elements which would render the hotspots over the content (but they would always be there, they would not appear when hovering over the image and disappear afterwards.
Nicolas Delobel from Amplexor created support to render DITA image maps in PDF using an SVG layer over the original binary image:

https://github.com/Amplexor/com.amplexor.imagemap-pdf

Regards,
Radu

Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

On 1/25/2021 3:27 PM, David Hollis wrote:
Hi Pierre,
Are you sure that the PDF format properly renders a SVG file with a hot spot, and that the Reader displays it as a hot spot?
David

Hi,

I have a technical documentation with a lot of SVG files having hot spots.
Hotspots are managed using a javascript function call on g/@onmouseover attributes.
The function itself changes some opacity attributes of the graphic.
The HTML production works fine and all hotspots are active.

Using the same SVG, with the standard DITA-OT PDF (XSL-FO) plugin, the hotspots are no more active and all images are flats.

So, does someone foud a solution, a workaround, for keeping these kind SVG hotspots actives ?
Is there an other way to code SVG for being able to make them interactive both on PDF and HTML ?

Thanks for sharing any idea, solution,

Pierre


Re: PDF production with SVG having hot spots

David Hollis
 

Hi Pierre,

Are you sure that the PDF format properly renders a SVG file with a hot spot, and that the Reader displays it as a hot spot?

David

Hi,

I have a technical documentation with a lot of SVG files having hot spots.
Hotspots are managed using a javascript function call on g/@onmouseover attributes.
The function itself changes some opacity attributes of the graphic.
The HTML production works fine and all hotspots are active.

Using the same SVG, with the standard DITA-OT PDF (XSL-FO) plugin, the hotspots are no more active and all images are flats.

So, does someone foud a solution, a workaround, for keeping these kind SVG hotspots actives ?
Is there an other way to code SVG for being able to make them interactive both on PDF and HTML ?

Thanks for sharing any idea, solution,

Pierre


Re: Hide a topic from PDF output at xsl level

Radu Coravu
 

Hi Balázs,

You seemed to find a solution for your problem on stackoverflow:

https://stackoverflow.com/questions/65668373/hide-a-topic-from-pdf-output-at-xsl-level

Do you have any problems with the solution you found or do you want to see if there are alternative solutions?

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 1/12/21 10:46, marczisbalazs@... wrote:

Hi All,

I have a topic, which only contains some metadata (childs of prolog and some custom elements too) of the documentation. The contents of these elements is displayed in headers and footers in the acutal PDF output.

My problem: now the referred topic itself included in the pdf as an empty chapter.


Setting the processing-role to resource-only or filtering the topic does not solve the problem, as the content of the elements is needed in the further steps of the transformation (headers, footerst ect..)


My best guess is to somehow exclude this one topic and the needless page sequence based on its ID with..


.. adding some attributes in a custom xsl template?

.. modification of topic processing?

.. an obvious method that didn’t occur to me?


I’m a beginner, so a little guidance would be nice.


Currently using: DITA-OT 2.1; Oxygen 17.1; Bookmap spec.; XSL FO based transformations;


Thanks in advance!


  


Hide a topic from PDF output at xsl level

marczisbalazs@...
 

Hi All,

I have a topic, which only contains some metadata (childs of prolog and some custom elements too) of the documentation. The contents of these elements is displayed in headers and footers in the acutal PDF output.

My problem: now the referred topic itself included in the pdf as an empty chapter.


Setting the processing-role to resource-only or filtering the topic does not solve the problem, as the content of the elements is needed in the further steps of the transformation (headers, footerst ect..)


My best guess is to somehow exclude this one topic and the needless page sequence based on its ID with..


.. adding some attributes in a custom xsl template?

.. modification of topic processing?

.. an obvious method that didn’t occur to me?


I’m a beginner, so a little guidance would be nice.


Currently using: DITA-OT 2.1; Oxygen 17.1; Bookmap spec.; XSL FO based transformations;


Thanks in advance!


Re: links within a chunked map?

Irina Barinova
 

Hello Tonia,

Could you please provide a bit more information?
Which tools are you using?
How did you customize xrefs and coded your mini-toc? 

Best regards,
Iryna Barinova 
Intelliarts.com

On Thu, Jan 21, 2021 at 5:24 AM Tonia <sharpwriter@...> wrote:
Hi all,
I'm having an issue with chunking a map and the internal links not working.

I have a map that I want to generate to one HTML file, and that is working. However, I coded a mini-toc for navigation (because the child topics don't show up in the main toc, by my design).  The xref links are breaking in the generated HTML and are just dead.

Part of me thinks this makes sense because the file hasn't been generated as a separate HTML file that can be linked to, but is there a workaround for this?

I hope I'm explaining it well enough.

Here's a copy of my map:

<map><title>Recycle Bin</title>
   
    <topicref href="../topics/c-recycle-bin.dita" chunk="to-content">
        <topicref href="../topics/c-bulk-actions-recycle-bin.dita" toc="no"/>
        <topicref href="../topics/t-filter-recycle-bin.dita" toc="no"/>
        <topicref href="../topics/t-modify-columns-recycle-bin.dita" toc="no"/>
    </topicref>
</map>

And within the c-recycle-bin.dita file, I have a list of links like this:

  <p>This section includes the following topics:</p>
    <ul id="ul_qsm_cw5_j4b">
      <li><xref href="c-recycle-bin-bulk-actions.dita"></xref></li>
      <li><xref href="t-filter-recycle-bin.dita"></xref></li>
      <li><xref href="t-modify-columns-recycle-bin.dita"></xref></li>
</ul>


What has to be done for this to work upon generation with the chunk element?

Thanks for your help,
Tonia

Rally Software Content Experience Lead


PDF production with SVG having hot spots

Pierre Attar
 

Hi,

I have a technical documentation with a lot of SVG files having hot spots.
Hotspots are managed using a javascript function call on g/@onmouseover attributes.
The function itself changes some opacity attributes of the graphic.
The HTML production works fine and all hotspots are active.

Using the same SVG, with the standard DITA-OT PDF (XSL-FO) plugin, the hotspots are no more active and all images are flats.

So, does someone foud a solution, a workaround, for keeping these kind SVG hotspots actives ?
Is there an other way to code SVG for being able to make them interactive both on PDF and HTML ?

Thanks for sharing any idea, solution,

Pierre


Re: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #keys #conref

Radu Coravu
 

Hi Jay,

Please see some answers below:

Could you provide details on the differences between the vanilla DITA-OT, and the DITA-OT with the various small fixes bundled in the Oxygen Publishing Englne?

Good question, right now our Oxygen Publishing Engine available on the web site is based on DITA OT 3.5.4.

It has extra patches for:

https://github.com/dita-ot/dita-ot/issues/3551

https://github.com/dita-ot/dita-ot/issues/2827

https://github.com/dita-ot/dita-ot/issues/2920

https://github.com/dita-ot/dita-ot/issues/3353

https://github.com/dita-ot/dita-ot/issues/3565

https://github.com/dita-ot/dita-ot/issues/3619

https://github.com/dita-ot/dita-ot/issues/3584

https://github.com/dita-ot/dita-ot/issues/3597

On each of those issues I added comments explaining how I attempted to fix things on my side.

Are fixes delivered as jar files to add to the classpath in the plugin.xml?

The fixes are delivered with a special DITA OT plugin named "com.oxygenxml.dost.patches" and they only work with a specific DITA OT version (in this case 3.5.4).
Are these fixes specific to publishing with Oxygen or can they be used for any output type?

The fixes I enumerated above are for any output type, most of them are in the DITA OT pre processing stages which are similar for any output type.


Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 1/22/21 22:44, Jay Sadler wrote:

Hi Radu,

Could you provide details on the differences between the vanilla DITA-OT, and the DITA-OT with the various small fixes bundled in the Oxygen Publishing Englne?

Are fixes delivered as jar files to add to the classpath in the plugin.xml?

Are these fixes specific to publishing with Oxygen or can they be used for any output type?

Jay

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Radu Coravu via groups.io
Sent: Friday, January 22, 2021 5:53 AM
To: main@dita-users.groups.io
Subject: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #conref #keys

 

External Email - DO NOT CLICK links or attachments unless you recognize the sender and are expecting the email.


Hi Christina,

Maybe you can create a small sample DITA project exemplifying the problem and attach it to an email.

The DITA OT bundled with Oxygen also comes with various small fixes made to the open source DITA OT distribution.

We deliver it as a separate download named Oxygen Publishing Engine, it is available for download here:

https://www.oxygenxml.com/publishing_engine.html

Maybe you can try to run the transformation from the command line, for example to produce the PDF. If it properly generates the output but the DITA OT 3.5.4 downloaded from the DITA OT web site does not, then probably one of our fixes might responsible for that.

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 1/22/21 14:27, stinakab via groups.io wrote:

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina

 

  


Re: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #keys #conref

Jay Sadler
 

Hi Radu,

Could you provide details on the differences between the vanilla DITA-OT, and the DITA-OT with the various small fixes bundled in the Oxygen Publishing Englne?

Are fixes delivered as jar files to add to the classpath in the plugin.xml?

Are these fixes specific to publishing with Oxygen or can they be used for any output type?

Jay

 

From: main@dita-users.groups.io <main@dita-users.groups.io> On Behalf Of Radu Coravu via groups.io
Sent: Friday, January 22, 2021 5:53 AM
To: main@dita-users.groups.io
Subject: [EXTERNAL] Re: [dita-users] Keyrefs no longer resolved within conrefs #conref #keys

 

External Email - DO NOT CLICK links or attachments unless you recognize the sender and are expecting the email.


Hi Christina,

Maybe you can create a small sample DITA project exemplifying the problem and attach it to an email.

The DITA OT bundled with Oxygen also comes with various small fixes made to the open source DITA OT distribution.

We deliver it as a separate download named Oxygen Publishing Engine, it is available for download here:

https://www.oxygenxml.com/publishing_engine.html

Maybe you can try to run the transformation from the command line, for example to produce the PDF. If it properly generates the output but the DITA OT 3.5.4 downloaded from the DITA OT web site does not, then probably one of our fixes might responsible for that.

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 1/22/21 14:27, stinakab via groups.io wrote:

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina

 


[ann][webinar] Engage everyone in the technical documentation process #Oxygen

alin_belu@...
 

Hello, 
 
We at Oxygen XML strongly think that anyone can contribute to the technical documentation with the proper collaboration tools! 
 
And next Wednesday (January 27), during the “Engage everyone in the technical documentation process” live webinar, Bogdan Dumitru, software developer at Syncro Soft, will show you how Oxygen Content Fusion is a platform for all, not just for technical writers. 
 
You will see firsthand how it can positively impact the activity of each person involved in the technical documentation process: 
* Technical writers who have full control over the content - the gatekeepers of the documentation source. 
* Subject matter experts (SMEs) who can create and push documentation drafts to technical writers. 
* Users that can now propose changes just by following a link in the published output. 
 
Along with the presented use-cases, this live event will also highlight DITA-specific features as well as some of the new additions brought to Content Fusion 4, in particular the concurrent editing support, allowing unrestricted access to edited files. 
 
This is a free event and you can register at http://www.oxygenxml.com/evs2021-5.html 
 
Make sure to check the full list of our upcoming events: https://www.oxygenxml.com/events_programme.html 
 
Best regards,
Alin
--
Alin Belu
Oxygen XML Editor


Re: Keyrefs no longer resolved within conrefs #keys #conref

Radu Coravu
 

Hi Christina,

Maybe you can create a small sample DITA project exemplifying the problem and attach it to an email.

The DITA OT bundled with Oxygen also comes with various small fixes made to the open source DITA OT distribution.

We deliver it as a separate download named Oxygen Publishing Engine, it is available for download here:

https://www.oxygenxml.com/publishing_engine.html

Maybe you can try to run the transformation from the command line, for example to produce the PDF. If it properly generates the output but the DITA OT 3.5.4 downloaded from the DITA OT web site does not, then probably one of our fixes might responsible for that.

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 1/22/21 14:27, stinakab via groups.io wrote:

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina

  


Keyrefs no longer resolved within conrefs #keys #conref

stinakab
 

Hi,

We're currently switching from DITA OT 3.4.1 to DITA OT 3.5.4 (the latest version supported by Oxygen 23.0).
We use Oxygen for local builds and use a build server for publishing. We have customization plug-ins.
At first, it looked as if everything ran smoothly. Then we discovered that on the build server <keyword keyrefs="xxx"> are no longer resolved within conref elements.
All other keyrefs resolve properly. It's just the conrefs in which they don't resolve.
It used to work with 3.4.1, but somehow with 3.5.4 there seems to something wrong. In Oxygen 23.0, there are no issues when transformations are run.
This happens with PDF and webhelp responsive outputs.
I don't have the slightest idea why the keyrefs are no longer resolved.
Could anybody help me with this, please?

Christina


Re: Allow variables to be referenced from @scope="peer" maps

David Hollis
 

Hi Chris, Eliot,

It's obvious that the two products and their documentation share an environment because there is a mapref from one to the other. With that in mind, I'm struggling to understand why you are not keen to use one of the alternatives that you mention.

It might seem like a good idea for each product to manage its own keys and content, but surely that leads to product silos? One of the strengths of DITA is that it breaks silos down.

I'm also a little concerned that the solution Eliot suggests could lead to quite complicated key processing?

Maybe I'm missing something?

David

To implement this you have to do all the preprocessing on all the peer maps referenced so that you know what the key space in each referenced peer map is.

That would be very inefficient in a naïve implementation because every time you ran map A that references peer B you'd also have to process peer B.

An obvious solution is to implement some kind of "key service" that maintains a persistent resolved key space for each map such that a processor can just ask for the resolved value of a given key in a given map. Of course, there are a number of potential issues here, including: how do you know when to update your persistent store? How do you handle runtime conditions, in particular, active filtering settings (DITAVAL)?

You start to see that this is the domain of content management where you have systems that have general knowledge of bodies of DITA content, track their status, versions, etc.

A relatively simplistic key service probably wouldn't be that difficult to implement (and my now-fallow DITA for Small Teams link manager application was working towards being a key service, among other things) but probably way outside the scope of the Open Toolkit project.

I've thought for a while that it would be useful to have a general key access API that defines the minimum features for DITA key stores. Given such an API a tool like Open Toolkit could have general key store requests that are then resolved against whatever key store you happen to have made a available, if any. A REST API could be implemented in any number of common technologies (Java, JavaScript, XQuery, etc.).

Another brute force solution would be to have Open Toolkit write out an easy-to-access representation of a given publication's key space whenever it's processed (or on request as a runtime option). When resolving peer references, could then try to find the key space data file and use it if found. This would leave it up to users to make sure that the key spaces were up to date, basically, processing every publication once and then processing them a second time to ensure they've used up to date key spaces from any peer publications.

Essentially, using peer maps takes you from having a collection of otherwise-independent publications to having a system of interdependent publications. As soon as you have that you have unavoidable management problems inherent in trying to produce deliverables from these interdependent publications, problems that are solvable but require some kind of content management system that maintains knowledge about all the publications, their components, their versions, their relationships to each other, provides processing optimizations (indexes, caches, etc.).

Or you have to create ad-hoc solutions that take advantage of simplifying assumptions you can make about your content or constraints you can impose on your content (and its authors). For example, for your purposes, it might be sufficient to have some kind of script that reads peer maps and generates sets of key definitions to be used in the referencing publications as local-scope key definitions. That's relatively easy to do but you then have to keep these generated key definition sets up to date as the publications are modified.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 1/21/21, 5:39 PM, "Chris Papademetrious" <main@dita-users.groups.io on behalf of chrispitude@gmail.com> wrote:

Hi everyone,

This is an FYI for an enhancement request I filed for the DITA-OT, in case anyone else would find it useful too:

Allow variables to be referenced from @scope="peer" maps #3685 <https://github.com/dita-ot/dita-ot/issues/3685>

The text is as follows:
Description
I have two books, bookA and bookB. bookA references bookB as a @scope="peer" map:

<map>
<title>Book A Map</title>
<mapref href="bookB.ditamap" scope="peer" keyscope="bookB" processing-role="resource-only"/>
<!-- ^^^^^^^^^^^^^ ^^^^ ^^^^^
...
</map>


In a topic in bookA, I would like to reference a "Product" variable from bookB:

<p>BookB provides more information on <ph keyref="bookB.Product"/>.</p>
<!-- ^^^^^^^^^^^^^ -->

Unfortunately, @scope="peer" suppresses all bookB content from the bookA transformation - topic content and variable definitions.

This enhancement requests that keyscoped @scope="peer" maps pull their keys (but not topics) from the referenced map into the current map.

To test this, unarchive the following testcase:

#### ditaot_keys_from_peer_books.zip ####

then run

dita -i bookA.ditamap -i bookA.ditamap -f html5 -o out
Possible Solution
I tried implementing a proof-of-concept solution, which you can see in the testcase directory as follows:

diff maprefImpl.xsl.ORIG maprefImpl.xsl.NEW

The attempt was to remember when we're in a @scope="peer-with-keys" context, that would keep all mapref contents except topic references. Unfortunately, even this naive attempt did not work - the variables still did not resolve, and bookB topics still showed up in the bookA output directory. (You will need to change @scope="peer" to @scope="peer-with-keys" to try this proof-of-concept on the provided testcase.)
Potential Alternatives
I am aware of warehouse topics, shared key definition files, etc. However, those are not a good fit for this need. This enhancement is for the case where we're already referencing a peer book and that book already defines the variables we want (for its own use), and we simply want to access them as well.


Re: Insert current timestamp as a value to an attribute?

Radu Coravu
 

Hello Wito,

I'm glad this works for you now, I will correct the screenshot in the blog post.

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 1/22/21 12:07, Wito Zoerkler wrote:

Hello Radu,
 
Thank you very much for your advice. With the quoted element, it now also works for me with the Activation XPath.
Could it be that the quotation marks for the "created" element in the Activation XPath are missing in the example screenshot under Adding a Custom Author Action to the Content Completion Window (oxygenxml.com)?
 
Best regards
Wito

  


Re: Insert current timestamp as a value to an attribute?

Wito Zoerkler
 

Hello Radu,
 
Thank you very much for your advice. With the quoted element, it now also works for me with the Activation XPath.
Could it be that the quotation marks for the "created" element in the Activation XPath are missing in the example screenshot under Adding a Custom Author Action to the Content Completion Window (oxygenxml.com)?
 
Best regards
Wito


Re: Allow variables to be referenced from @scope="peer" maps

ekimber@contrext.com
 

To implement this you have to do all the preprocessing on all the peer maps referenced so that you know what the key space in each referenced peer map is.

That would be very inefficient in a naïve implementation because every time you ran map A that references peer B you'd also have to process peer B.

An obvious solution is to implement some kind of "key service" that maintains a persistent resolved key space for each map such that a processor can just ask for the resolved value of a given key in a given map. Of course, there are a number of potential issues here, including: how do you know when to update your persistent store? How do you handle runtime conditions, in particular, active filtering settings (DITAVAL)?

You start to see that this is the domain of content management where you have systems that have general knowledge of bodies of DITA content, track their status, versions, etc.

A relatively simplistic key service probably wouldn't be that difficult to implement (and my now-fallow DITA for Small Teams link manager application was working towards being a key service, among other things) but probably way outside the scope of the Open Toolkit project.

I've thought for a while that it would be useful to have a general key access API that defines the minimum features for DITA key stores. Given such an API a tool like Open Toolkit could have general key store requests that are then resolved against whatever key store you happen to have made a available, if any. A REST API could be implemented in any number of common technologies (Java, JavaScript, XQuery, etc.).

Another brute force solution would be to have Open Toolkit write out an easy-to-access representation of a given publication's key space whenever it's processed (or on request as a runtime option). When resolving peer references, could then try to find the key space data file and use it if found. This would leave it up to users to make sure that the key spaces were up to date, basically, processing every publication once and then processing them a second time to ensure they've used up to date key spaces from any peer publications.

Essentially, using peer maps takes you from having a collection of otherwise-independent publications to having a system of interdependent publications. As soon as you have that you have unavoidable management problems inherent in trying to produce deliverables from these interdependent publications, problems that are solvable but require some kind of content management system that maintains knowledge about all the publications, their components, their versions, their relationships to each other, provides processing optimizations (indexes, caches, etc.).

Or you have to create ad-hoc solutions that take advantage of simplifying assumptions you can make about your content or constraints you can impose on your content (and its authors). For example, for your purposes, it might be sufficient to have some kind of script that reads peer maps and generates sets of key definitions to be used in the referencing publications as local-scope key definitions. That's relatively easy to do but you then have to keep these generated key definition sets up to date as the publications are modified.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 1/21/21, 5:39 PM, "Chris Papademetrious" <main@dita-users.groups.io on behalf of chrispitude@gmail.com> wrote:

Hi everyone,

This is an FYI for an enhancement request I filed for the DITA-OT, in case anyone else would find it useful too:

Allow variables to be referenced from @scope="peer" maps #3685 <https://github.com/dita-ot/dita-ot/issues/3685>

The text is as follows:
Description
I have two books, bookA and bookB. bookA references bookB as a @scope="peer" map:

<map>
<title>Book A Map</title>
<mapref href="bookB.ditamap" scope="peer" keyscope="bookB" processing-role="resource-only"/>
<!-- ^^^^^^^^^^^^^ ^^^^ ^^^^^
...
</map>


In a topic in bookA, I would like to reference a "Product" variable from bookB:

<p>BookB provides more information on <ph keyref="bookB.Product"/>.</p>
<!-- ^^^^^^^^^^^^^ -->

Unfortunately, @scope="peer" suppresses all bookB content from the bookA transformation - topic content and variable definitions.

This enhancement requests that keyscoped @scope="peer" maps pull their keys (but not topics) from the referenced map into the current map.

To test this, unarchive the following testcase:

#### ditaot_keys_from_peer_books.zip ####

then run

dita -i bookA.ditamap -i bookA.ditamap -f html5 -o out
Possible Solution
I tried implementing a proof-of-concept solution, which you can see in the testcase directory as follows:

diff maprefImpl.xsl.ORIG maprefImpl.xsl.NEW

The attempt was to remember when we're in a @scope="peer-with-keys" context, that would keep all mapref contents except topic references. Unfortunately, even this naive attempt did not work - the variables still did not resolve, and bookB topics still showed up in the bookA output directory. (You will need to change @scope="peer" to @scope="peer-with-keys" to try this proof-of-concept on the provided testcase.)
Potential Alternatives
I am aware of warehouse topics, shared key definition files, etc. However, those are not a good fit for this need. This enhancement is for the case where we're already referencing a peer book and that book already defines the variables we want (for its own use), and we simply want to access them as well.


Allow variables to be referenced from @scope="peer" maps

Chris Papademetrious
 

Hi everyone,

This is an FYI for an enhancement request I filed for the DITA-OT, in case anyone else would find it useful too:

Allow variables to be referenced from @scope="peer" maps #3685

The text is as follows:

Description

I have two books, bookA and bookB. bookA references bookB as a @scope="peer" map:

<map>
  <title>Book A Map</title>
  <mapref href="bookB.ditamap" scope="peer" keyscope="bookB" processing-role="resource-only"/>
  <!--          ^^^^^^^^^^^^^         ^^^^            ^^^^^
  ...
</map>


In a topic in bookA, I would like to reference a "Product" variable from bookB:

<p>BookB provides more information on <ph keyref="bookB.Product"/>.</p>
<!--                                              ^^^^^^^^^^^^^ -->

Unfortunately, @scope="peer" suppresses all bookB content from the bookA transformation - topic content and variable definitions.

This enhancement requests that keyscoped @scope="peer" maps pull their keys (but not topics) from the referenced map into the current map.

To test this, unarchive the following testcase:

#### ditaot_keys_from_peer_books.zip ####

then run

dita -i bookA.ditamap -i bookA.ditamap -f html5 -o out

Possible Solution

I tried implementing a proof-of-concept solution, which you can see in the testcase directory as follows:

diff maprefImpl.xsl.ORIG maprefImpl.xsl.NEW

The attempt was to remember when we're in a @scope="peer-with-keys" context, that would keep all mapref contents except topic references. Unfortunately, even this naive attempt did not work - the variables still did not resolve, and bookB topics still showed up in the bookA output directory. (You will need to change @scope="peer" to @scope="peer-with-keys" to try this proof-of-concept on the provided testcase.)

Potential Alternatives

I am aware of warehouse topics, shared key definition files, etc. However, those are not a good fit for this need. This enhancement is for the case where we're already referencing a peer book and that book already defines the variables we want (for its own use), and we simply want to access them as well.


links within a chunked map?

Tonia
 

Hi all,
I'm having an issue with chunking a map and the internal links not working.

I have a map that I want to generate to one HTML file, and that is working. However, I coded a mini-toc for navigation (because the child topics don't show up in the main toc, by my design).  The xref links are breaking in the generated HTML and are just dead.

Part of me thinks this makes sense because the file hasn't been generated as a separate HTML file that can be linked to, but is there a workaround for this?

I hope I'm explaining it well enough.

Here's a copy of my map:

<map><title>Recycle Bin</title>
   
    <topicref href="../topics/c-recycle-bin.dita" chunk="to-content">
        <topicref href="../topics/c-bulk-actions-recycle-bin.dita" toc="no"/>
        <topicref href="../topics/t-filter-recycle-bin.dita" toc="no"/>
        <topicref href="../topics/t-modify-columns-recycle-bin.dita" toc="no"/>
    </topicref>
</map>

And within the c-recycle-bin.dita file, I have a list of links like this:

  <p>This section includes the following topics:</p>
    <ul id="ul_qsm_cw5_j4b">
      <li><xref href="c-recycle-bin-bulk-actions.dita"></xref></li>
      <li><xref href="t-filter-recycle-bin.dita"></xref></li>
      <li><xref href="t-modify-columns-recycle-bin.dita"></xref></li>
</ul>


What has to be done for this to work upon generation with the chunk element?

Thanks for your help,
Tonia

Rally Software Content Experience Lead

361 - 380 of 46324