Date   

Re: Multiple links to same topic #linking #PDF

Radu Coravu
 

Hi Marisa,

I'm afraid I cannot reproduce your problem with DITA OT 3.6.

What DITA OT version are you using? Do you have extra PDF customizations? Can you maybe come up with a small trimmed down DITA project (a map and a couple of topics) exemplifying the problem?

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 2/23/21 02:53, mganir via groups.io wrote:

I have a long topic with more than one xref to a reference topic in the same project. When I transform to PDF, the first link to the reference topic works, but the second one does not. The text for the link is displayed (See Reference topic), but the link is broken. I have tried this with other files and other links, and an xref that is used more than once in a single topic is always broken on the second or third instance. When I output to webhelp, all the links work. 

Does anyone know what the issue might be in the PDF transform?

Thanks, 
Marisa

  


Multiple links to same topic #linking #PDF

mganir@...
 

I have a long topic with more than one xref to a reference topic in the same project. When I transform to PDF, the first link to the reference topic works, but the second one does not. The text for the link is displayed (See Reference topic), but the link is broken. I have tried this with other files and other links, and an xref that is used more than once in a single topic is always broken on the second or third instance. When I output to webhelp, all the links work. 

Does anyone know what the issue might be in the PDF transform?

Thanks, 
Marisa


release 3.6.1

Aliza Merzel
 

HI,

 

Is there a planned release date for DITA-OT 3.6.1?

I need to implement https://github.com/dita-ot/dita-ot/issues/3689 for a customer

 

Thanks,

Aliza


DITA-ditaot-utilities - easily install the latest DITA-OT

Chris Papademetrious
 

If anyone is interested, I created a simple linux script to install the latest DITA-OT:

https://github.com/chrispy-snps/DITA-ditaot-utilities

Feedback is welcomed!

 - Chris


Re: AntennaHouse PDF ML

Bill Burns
 

Thank you for the insight, Toshihiko-san.

Bill


On Fri, Feb 12, 2021 at 1:04 AM Toshihiko Makita <tmakita@...> wrote:
Hi Bill,

Thank you for paying your attention to PDF5-ML plug-in.
In Japan, I hear that most of DITA developers use PDF5-ML plug-in as the base for their DITA users. We (Antenna House) also use this plug-in for PDF generation as the base plug-in for user customization.
In the world-wide, I have many customization requests through GitHub issue tracker and many of them are implemented. (Continued table header & footer, floating figure, dynamic paper size assignment, conditional style definition etc.)

However, the defects also exist. The language resources (literals) are not prepared in comparison of PDF2 plug-in. The user who uses PDF5-ML plug-in must prepare these resources by themselves. Also I’ve tested this plug-in with AH Formatter only and the plug-in uses several AH Formatter specific extensions (FO properties prefixed by “axf:”) to get better formatting results.

Hope this helps your understanding.

Regards,
-- 
/*-----------------------------------------------------------------------
 Toshihiko Makita
 Development Group. Antenna House, Inc. Ina Branch
 Web site:
 http://www.antenna.co.jp/
 http://www.antennahouse.com/
 ------------------------------------------------------------------------*/ 



--
Bill Burns
512-646-2100
--
We are [A] 


Re: Table of content question #FOP #DITA-OT #XSLT

chichak1995@...
 

On Tue, Feb 16, 2021 at 02:04 AM, Nicolas Delobel wrote:
toc.xsl
Hi Nicolas,

thank you for the fast answer.

Br,
Chicak


Re: Table of content question #FOP #DITA-OT #XSLT

Nicolas Delobel
 

Hi Chichak,

In DITA-OT, toc is generated with this XSLT:
dita-ot-3.X/plugins/org.dita.pdf2/xsl/fo/toc.xsl

Br,
Nicolas


Table of content question #FOP #DITA-OT #XSLT

chichak1995@...
 

Hi dita experts,

is there a way to edit how TOC will look like? I want my main topic to be larger and have a little padding below it just like on oracle documentation (https://docs.oracle.com/cd/E11882_01/server.112/e10575.pdf).

A place where TOC is generated would be a great start for me if anyone can point me at it.

Br,
Chichak


Re: <resourceid> element's @appid attribute

ekimber@contrext.com
 

Radu's approach works *as long as* topic IDs and/or filenames are unique across your corpus of topics. There is nothing in the DITA standard that requires either of those two conditions to be true.

Because I'm that guy, I make a point of making every topic ID "topicid" when I can to ensure that systems and processors that assume topic IDs are always unique will break. Likewise, in a given corpus, you might have many topics with a filename of "introduction.dita" or something [Full disclosure: I built a DITA import process for a product I used to work on where it broke when filenames were not unique--that was particularly painful because I discovered the breakage when I tried to import a set of data I had created: the DITA version of John Bosak's XML Shakespeare's Plays. Hoist on my own petard.].

Of course, the full URI of any given topic is unique, so using a hash of the URI would always produce a unique value but that's not very human friendly.

The most general solution would be to either use <resourceid> within topics to assign unique names within some appropriate scope (might be your full corpus, might be just for a given product's documentation, or a library of products, or whatever) or to use keys as the basis of deliverable anchors.

Putting <resourceid> in topics where you ensure the <resourceid> values are appropriately unique makes the topics independently globally named (that is, you aren't relying on keys defined in maps to get name uniqueness). It serves the same purpose that Radu's ID- or filename-based approach does but doesn't limit your choices for either IDs or filenames, which might have other forces that need to control their values in a way that doesn't necessarily guarantee uniqueness.

I'm starting to see <resourceid> as the best way to manage global identifier uniqueness separate from keys, IDs, or filenames. It has several advantages over using any of the other available identifiers:

* Can have completely independent business rules.
* Can have different rules for different use environments (different deliverables, different tools, different business rules)
* Can have multiple resource IDs for the same resource
* Topics can assert their own resource IDs (topics cannot assert their own keys using DITA-defined mechanisms)

If you consider the use case of needing to migrate your content to a new organizational strategy or a new storage model, that likely means a change to some or all filenames or a change to your key naming strategy or some other potentially disruptive change. Because resource IDs are separate from these, they can be unaffected by this sort of source-level change. You might also decide to change your information architecture approach, which can change how you use keys, requiring a change to key names (or the addition of new keys to reflect the new architecture).

For people just starting out with DITA, it's probably hard to imagine how these name-management concerns are important, but once you've been using DITA for a few years, you will almost certainly be faced with some kind of disruptive change to how your DITA source is stored and managed, or a change to your Information Architecture approach, that requires modifying keys, filenames, or IDs. It will happen.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 2/14/21, 10:41 PM, "Radu Coravu" <main@dita-users.groups.io on behalf of radu_coravu@sync.ro> wrote:






Hi John,
Our WebHelp feature which generates context ids used to link to
topics looks at both the @id attribute of the topic and at the
"resourceid" element. As topic IDs are required and need to be
specified inside the DITA topic anyway we decided to use the topic
ID as the context id, and added some Schematron rules to insure
that the topic ID always matches the file name, to provide some
kind of uniqueness of the topic ID in the entire DITA project
context.

Regards,
Radu
Radu Coravu
Oxygen XML Editor

On 2/13/21 04:27,
john.kirkilis@nokia.com wrote:



Hi Radu,

In the hopes of finding an example document set, I downloaded the
Oxygen userguide source from GitHub and couldn't find any
instances of <resourceid> being used anywhere in the
content. I thought perhaps that's how you linked to your web help
from Oxygen's help icon in every dialog box.

Regards,

John


Re: <resourceid> element's @appid attribute

Radu Coravu
 

Hi John,

Our WebHelp feature which generates context ids used to link to topics looks at both the @id attribute of the topic and at the "resourceid" element. As topic IDs are required and need to be specified inside the DITA topic anyway we decided to use the topic ID as the context id, and added some Schematron rules to insure that the topic ID always matches the file name, to provide some kind of uniqueness of the topic ID in the entire DITA project context.

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 2/13/21 04:27, john.kirkilis@... wrote:

Hi Radu,

In the hopes of finding an example document set, I downloaded the Oxygen userguide source from GitHub and couldn't find any instances of <resourceid> being used anywhere in the content. I thought perhaps that's how you linked to your web help from Oxygen's help icon in every dialog box.

Regards,

John

  


Re: <resourceid> element's @appid attribute

john.kirkilis@...
 

Hi Radu,

In the hopes of finding an example document set, I downloaded the Oxygen userguide source from GitHub and couldn't find any instances of <resourceid> being used anywhere in the content. I thought perhaps that's how you linked to your web help from Oxygen's help icon in every dialog box.

Regards,

John


Re: <resourceid> element's @appid attribute

john.kirkilis@...
 

I need a diagram with content on one side and a UX mock-up on the other, with arrows, cardinality/ordinality, and example values... either that or an old priest and a young priest to perform a brain-worm exorcism.


Re: Help with filtering in com.elovirta.ooxml #conditional-processing

Jonathan Hanna
 

Well, I decided to have some fun this afternoon by furthering my knowledge about how ditaval flags work during processing. I think I now have a better solution than what I proposed earlier. Instead of using the XSLT template I provided in the previous message, try the following:

  <xsl:template match="*[ditaval-startprop/prop[@backcolor]]" mode="inline-style">
    <xsl:param name="backcolor" select="ditaval-startprop/prop/@backcolor"/>        
    <w:highlight w:val="{$backcolor}"/>
  </xsl:template>

Again, my XSLT knowledge isn't the best, so there's probably a better way to do this. However, from my brief testing, this seems to work pretty well! I tested this with three different colors (red, green, and blue) and each color appeared in Word as specified in the ditaval file.

Best Regards,
Jonathan


Re: Help with filtering in com.elovirta.ooxml #conditional-processing

Jonathan Hanna
 

Hi Leigh,

I'd like to preface this by saying that I'm fairly new to DITA (~1 year experience), so my solution is definitely not the best :-). However, I have experience making customizations to the com.elovirta.ooxml over the past year, so maybe I can provide you with a good place to start.

As far as I know, flagging content is not currently supported in the plugin (although filtering is). As a workaround, you can create a custom document.xsl file that contains a custom XSLT rule to highlight content in Word. When running the plugin, you will need to set the document.xsl parameter to the file path of your custom document.xsl file.

To create the custom file:
  1. Make a copy of the document.xsl file provided with the plugin.
  2. The document.xsl file imports many .xsl files in the plugin. In the new document.xsl file, you will need to append plugin:com.elovirta.ooxml:docx/word/ to the href of each imported file. For example, change <xsl:import href="document.utils.xsl"/> to <xsl:import href="plugin:com.elovirta.ooxml:docx/word/document.utils.xsl"/>.
  3. In the new file, add the following XSLT to the end of the file:
    <xsl:template match="*[contains(@audience, 'optional')]" mode="inline-style">
        <w:highlight w:val="yellow"/>
    </xsl:template>


I've attached a custom document.xsl file as an example. There are obvious limitations to this method, such as associating the color yellow with the value of the audience attribute instead of the ditaval property. For example, if you changed the backcolor attribute to green in the ditaval file you would still see a yellow highlight in Word. If I knew how to select properties set in a ditaval file, that would be a much better solution. Hopefully the above at least provides a good start to a better solution.

Best Regards,
Jonathan


Re: <resourceid> element's @appid attribute

Julio J Vazquez
 

Because Microsoft doesn't really support CHM anymore, does it make sense to bring across that sort of baggage into 2.0? Should we remove the unneeded and move forward with required attributes? Because 2.0 doesn't need to be backward compatible, remove the chaff.


Julio J. Vazquez


Re: AntennaHouse PDF ML

Toshihiko Makita
 

Hi Bill,

Thank you for paying your attention to PDF5-ML plug-in.
In Japan, I hear that most of DITA developers use PDF5-ML plug-in as the base for their DITA users. We (Antenna House) also use this plug-in for PDF generation as the base plug-in for user customization.
In the world-wide, I have many customization requests through GitHub issue tracker and many of them are implemented. (Continued table header & footer, floating figure, dynamic paper size assignment, conditional style definition etc.)

However, the defects also exist. The language resources (literals) are not prepared in comparison of PDF2 plug-in. The user who uses PDF5-ML plug-in must prepare these resources by themselves. Also I’ve tested this plug-in with AH Formatter only and the plug-in uses several AH Formatter specific extensions (FO properties prefixed by “axf:”) to get better formatting results.

Hope this helps your understanding.

Regards,
-- 
/*-----------------------------------------------------------------------
 Toshihiko Makita
 Development Group. Antenna House, Inc. Ina Branch
 Web site:
 http://www.antenna.co.jp/
 http://www.antennahouse.com/
 ------------------------------------------------------------------------*/


Re: <resourceid> element's @appid attribute

Bill Burns
 

Just some historical perspective here. Microsoft HTML Help (CHM) requires a numeric context ID (the value of @appid) and a topic id (the value of context @ux-context-string) to complete the CS help mappings. The context ID is mapped to the topic ID in a header file (which can come from app developers or can be maintained by hand), and the topic ID is mapped to the topic files in the hhp file (which also has a link to the header file). You can find Microsoft's guidelines here. Kind of an early approach to indirect referencing as you can swap out header files to establish new link targets.


On Thu, Feb 11, 2021 at 7:43 AM ekimber@... <ekimber@...> wrote:
The @appid attribute is specifying the application-specific ID to be associated with the topic (or topicref-referenced resource).

So @appname names the application, @appid is the ID by which the application will point to the topic.

Rereading the description of resourceid now, it's not actually clear to me what the functional difference between @appid and @ux-context-string is, but I know the designers of the UX-specific features had a reason for it.

Based on the proposed 2.0 semantics for <resourceid>, I think the distinction between @appid and @ux-context-string is that @appid *contributes* to the final deliverable anchor while @ux-context-string *is* the anchor (help-specific context identifier). That is, @appid can apply to any kind of anchor for any kind of deliverable, while @ux-context-string is specifically for context-sensitive help and is intended to be used exactly as specified.

Another detail is that @appid was added to correct the original design of <resourceid> where the @id attribute was used for what @appid is now used for. Using @id was incorrect because @id always identifies the *element* on which it appears.

I agree that the names @appname and @appid are not as clear as they could be--in the process of preparing the DITA 2.0 proposal (Issue 33, replace @copy-to), I had to keep reminding myself that @appid is the ID and @appname is the application name.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 2/10/21, 7:06 PM, "main@dita-users.groups.io on behalf of john.kirkilis@..." <main@dita-users.groups.io on behalf of john.kirkilis@...> wrote:

    On Wed, Feb 10, 2021 at 10:01 AM, ekimber@... wrote:

    An ID used by an application to identify the topic.

    Thanks Elliot for mentioning the DITA 2.0 proposal. I'll check it out.

    My question has more to do with the description of the @appid attribute. The @appname is obviously the name of the application that is being documented, such as "OxygenXML"or "Apache Tomcat", and the name "appid" would lead me to believe that it's a way to more specifically identify specific parts of the application identified by @appname, whether it be a page, tab, window, dialog box, form field, etc. However the description, "An ID used by an application to identify the topic" indicates to me that it's an id the application uses to refer to a documentation topic, not a part of the application, and the note which says that @appid should be used instead of the @id attribute in DITA 1.2's use of <resourceid> further makes it sound like its a way to refer to a DITA topic rather than an aspect of the application. In addition, the definition of @ux-context-string, "Contains the value of a user-assistance context-string that is used to identify the topic", confuses me as well by including "identify the topic" instead of ""further identify the context of the application" being documented.

    Perhaps, I'm being overly literal, but I would appreciate clarity on which attributes refer to aspects of the documentation and which refer to the application being documented.














--
Bill Burns
512-646-2100
--
We are [A] 


Re: <resourceid> element's @appid attribute

ekimber@contrext.com
 

The @appid attribute is specifying the application-specific ID to be associated with the topic (or topicref-referenced resource).

So @appname names the application, @appid is the ID by which the application will point to the topic.

Rereading the description of resourceid now, it's not actually clear to me what the functional difference between @appid and @ux-context-string is, but I know the designers of the UX-specific features had a reason for it.

Based on the proposed 2.0 semantics for <resourceid>, I think the distinction between @appid and @ux-context-string is that @appid *contributes* to the final deliverable anchor while @ux-context-string *is* the anchor (help-specific context identifier). That is, @appid can apply to any kind of anchor for any kind of deliverable, while @ux-context-string is specifically for context-sensitive help and is intended to be used exactly as specified.

Another detail is that @appid was added to correct the original design of <resourceid> where the @id attribute was used for what @appid is now used for. Using @id was incorrect because @id always identifies the *element* on which it appears.

I agree that the names @appname and @appid are not as clear as they could be--in the process of preparing the DITA 2.0 proposal (Issue 33, replace @copy-to), I had to keep reminding myself that @appid is the ID and @appname is the application name.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 2/10/21, 7:06 PM, "main@dita-users.groups.io on behalf of john.kirkilis@nokia.com" <main@dita-users.groups.io on behalf of john.kirkilis@nokia.com> wrote:

On Wed, Feb 10, 2021 at 10:01 AM, ekimber@contrext.com wrote:

An ID used by an application to identify the topic.

Thanks Elliot for mentioning the DITA 2.0 proposal. I'll check it out.

My question has more to do with the description of the @appid attribute. The @appname is obviously the name of the application that is being documented, such as "OxygenXML"or "Apache Tomcat", and the name "appid" would lead me to believe that it's a way to more specifically identify specific parts of the application identified by @appname, whether it be a page, tab, window, dialog box, form field, etc. However the description, "An ID used by an application to identify the topic" indicates to me that it's an id the application uses to refer to a documentation topic, not a part of the application, and the note which says that @appid should be used instead of the @id attribute in DITA 1.2's use of <resourceid> further makes it sound like its a way to refer to a DITA topic rather than an aspect of the application. In addition, the definition of @ux-context-string, "Contains the value of a user-assistance context-string that is used to identify the topic", confuses me as well by including "identify the topic" instead of ""further identify the context of the application" being documented.

Perhaps, I'm being overly literal, but I would appreciate clarity on which attributes refer to aspects of the documentation and which refer to the application being documented.


Re: <resourceid> element's @appid attribute

Kristen James Eberlein
 

John, if you have a question about the language used in the DITA specification (or suggestions about how to improve it), please send an e-mail to the dita-comment list.

The dita-comment list is the mechanism for folks outside of OASIS to communicate with the DITA TC. All dita-comment e-mails are added to the agenda for the weekly DITA TC call.

Here is a link for how you can subscribe to the dita-comment list: https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=dita

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
OASIS Distinguished Contributor
Principal consultant, Eberlein Consulting LLC
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)


On 2/10/2021 8:06 PM, john.kirkilis via groups.io wrote:
On Wed, Feb 10, 2021 at 10:01 AM, ekimber@... wrote:
An ID used by an application to identify the topic.
Thanks Elliot for mentioning the DITA 2.0 proposal. I'll check it out.

My question has more to do with the description of the @appid attribute. The @appname is obviously the name of the application that is being documented, such as "OxygenXML"or "Apache Tomcat", and the name "appid" would lead me to believe that it's a way to more specifically identify specific parts of the application identified by @appname, whether it be a page, tab, window, dialog box, form field, etc. However the description, "An ID used by an application to identify the topic" indicates to me that it's an id the application uses to refer to a documentation topic, not a part of the application, and the note which says that @appid should be used instead of the @id attribute in DITA 1.2's use of <resourceid> further makes it sound like its a way to refer to a DITA topic rather than an aspect of the application. In addition, the definition of @ux-context-string, "Contains the value of a user-assistance context-string that is used to identify the topic", confuses me as well by including "identify the topic" instead of ""further identify the context of the application" being documented.

Perhaps, I'm being overly literal, but I would appreciate clarity on which attributes refer to aspects of the documentation and which refer to the application being documented.


Re: <resourceid> element's @appid attribute

john.kirkilis@...
 

On Wed, Feb 10, 2021 at 10:01 AM, ekimber@... wrote:
An ID used by an application to identify the topic.
Thanks Elliot for mentioning the DITA 2.0 proposal. I'll check it out.

My question has more to do with the description of the @appid attribute. The @appname is obviously the name of the application that is being documented, such as "OxygenXML"or "Apache Tomcat", and the name "appid" would lead me to believe that it's a way to more specifically identify specific parts of the application identified by @appname, whether it be a page, tab, window, dialog box, form field, etc. However the description, "An ID used by an application to identify the topic" indicates to me that it's an id the application uses to refer to a documentation topic, not a part of the application, and the note which says that @appid should be used instead of the @id attribute in DITA 1.2's use of <resourceid> further makes it sound like its a way to refer to a DITA topic rather than an aspect of the application. In addition, the definition of @ux-context-string, "Contains the value of a user-assistance context-string that is used to identify the topic", confuses me as well by including "identify the topic" instead of ""further identify the context of the application" being documented.

Perhaps, I'm being overly literal, but I would appreciate clarity on which attributes refer to aspects of the documentation and which refer to the application being documented.

281 - 300 of 46295