Date   

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.


AntennaHouse PDF ML

Bill Burns
 

Hello!

Looking at recommending a base for some PDF plugins on a couple of projects. We're curious how many people are using the PDF5 ML plugin from AntennaHouse to base their plugs. It seems well designed and surprisingly nonproprietary given its origin. 

If you have used it as your base, what challenges have you encountered with it? How does it compare favorably to the PDF2 plugin?

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


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

Leigh White
 

Hi all,

I'm setting up the com.elovirta.ooxml plugin for a customer. Using with OT 2.5.4. They will be using @audience pretty extensively to both filter some elements, and color-code others. For the latter, I have set up a ditaval that flags content based on the value of @audience. This works exactly as expected for pdf outputs but seems to have no effect whatsoever for ooxml output. My knowledge of this plugin and ooxml in general is pretty slim. I'm wondering if the failure lies in the plugin--that it just doesn't account for flagging, or in the template---that some accommodation would need to be made there for displaying the background color? Looking at the CLEANED file, it appears that the flagging is preserved to that point:

<ditaval-startprop class="+ topic/foreign ditaot-d/ditaval-startprop " outputclass="background-color:yellow;">
<prop xmlns:dita-ot="http://dita-ot.sourceforge.net" action="flag" att="audience" backcolor="yellow" val="optional"/>
</ditaval-startprop>split up as indicated<ditaval-endprop class="+ topic/foreign ditaot-d/ditaval-endprop ">
<prop xmlns:dita-ot="http://dita-ot.sourceforge.net" action="flag" att="audience" backcolor="yellow" val="optional"/>
</ditaval-endprop>

So I'm not sure where it gets lost. Any help appreciated!

Thanks,
Leigh


Re: <resourceid> element's @appid attribute

ekimber@contrext.com
 

The intent of resourceid is to allow you to associate arbitrary, application-specific identifiers, with topics or other resources addressed by topicrefs.

So if by "representation" you mean "how do I tag it up?" I think the answer is: You create a topic with the help content, associate a resource IDs with it, and then include those IDs in the published help for the target system, whatever that means.

I think the implication here is that individual fields will need to be documented in individual topics, as opposed to within the body of a topic (i.e., in a table, definition list, using section elements, whatever).

There's no defined mechanism using <resourceid> to bind a resource ID to an element within a topic, which is what I think you're asking for. I could see a given help system providing some convention for that, i.e., combining the topic's resource ID with an element ID from within the topic to create a resolvable anchor in the published help, but that behavior would be beyond what the DITA standard defines.

DITA's naming and addressing architecture basically says "the unit of addressability exposed to the outside world is the topicref". This is implicit (or, arguably, explicit) in the fact that maps are the place where you can define globally-unique identifiers for things by using keys or resource IDs to bind names to the things the topicrefs reference in the context of a specific root map.

Because root maps have identity (they are objects in the general computer science sense of things that have identity within the set of all possible things), by definition, the names defined in them are globally unique (because the location of the root map establishes a unique base address for all the unique names defined in the map). In particular, keys are, by definition, unique within the scope of a given root map. In terms of Web architecture, every root map has a unique URI and thus establishes a unique base URI for all the names defined within that root map, making all the names globally unique among all URI-addressible resources. (This is true for XML documents generally but in DITA root maps have a special role in that root maps cannot themselves be re-used. That's what being "root" means: a map that is not re-used directly by any other map.) The implication is that, because root maps have global identity (unique URIs), deliverables produced from them also have global identity, so the uniqueness of identifiers in root maps carry over to the deliverables produced from those root maps (or, more precisely, can be carried over to the deliverables produced from those root maps, since deliverable production systems can do whatever they way, including breaking the inherent uniqueness of the identifiers in the DITA source--the most the DITA standard can do is define the required properties of the source content).

Resource IDs are not, by the rules of the DITA spec, globally unique because there's no rule that prevents you assigning the same application name/app-id pair to multiple topics or topcirefs in the context of a single root map, but you would normally want to do that in order for your published help system to work correctly. This allows you to keep the DITA-specific identifiers (keys) separate from any application-specific identifiers you need to publish to. It also allows adding new application-specific identifiers after the fact (to avoid, for example, having to modify existing keys or adding additional keys, which could be disruptive or difficult depending on how you are using or not using keys).

Note that for DITA 2.0 we have just accepted a proposal to extend <resourceid> to allow it to satisfy the requirements for which @copy-to is currently used.

This proposal doesn't change anything about the DITA 1.3 definition of <resourceid> but does extend it to play a more general role in defining deliverable-specific anchor information, something that @copy-to was designed to do but that it didn't really do very well. So for example, if you have the requirement to define, on a topicref, that the referenced topic should have a specific HTML filename in the published HTML rendering of that topic, <resourceid> in DITA 2.0 will allow you to say that more explicitly than you can today (although you can use <resourceid> for that today given appropriate support in your publishing tools and some tools in fact do that today, using <resourceid> app-ids to generate anchors in HTML).

The main thing we add to <resourceid> is a way for authors to indicate that a given <resourceid> element is providing deliverable anchor information instead of help system identifiers (the original intended use and what existing systems that use <resourceid> assume when there is no @appname value). We also refine and clarify how <resourceid> information should be used by processors in the construction of deliverable anchors (tl;dr: processors should use the <resourceid> information as much as possible in a clear and consistent way so that the deliverable anchors produced for a given deliverable are as predictable and repeatable as possible, understanding that the details of deliverable generation, including anchor construction, are necessarily processor dependent).

Cheers,

E.

--
Eliot Kimber
http://contrext.com


On 2/9/21, 7:07 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:

The DITA 1.3 spec describes the @appid attribute of the <resourceid> as follows:

An ID used by an application to identify the topic.

While the @ux-context-string is defined as:

Contains the value of a user-assistance context-string that is used to identify the topic.

What I'm not clear about is how a UX resource, whether it be a page of a webapp or an individual field in a webform, should be represented in DITA so that when a help icon is clicked on a UX widget in a webapp, the proper topic can be referenced.


Re: <resourceid> element's @appid attribute

Radu Coravu
 

Hi John,

Not sure if this answers your question but for example in the Oxygen WebHelp Responsive output we use the "resourceid" to gather such application IDs and redirect to the topics containing them when the application ID is given in a query string to the web help output:

https://www.oxygenxml.com/doc/versions/23.0/ug-editor/topics/whr-context-sensitive.html

Regards,

Radu

Radu Coravu
Oxygen XML Editor
On 2/10/21 03:07, john.kirkilis@... wrote:

The DITA 1.3 spec describes the @appid attribute of the <resourceid> as follows:
An ID used by an application to identify the topic.
While the @ux-context-string is defined as:
Contains the value of a user-assistance context-string that is used to identify the topic.
What I'm not clear about is how a UX resource, whether it be a page of a webapp or an individual field in a webform, should be represented in DITA so that when a help icon is clicked on a UX widget in a webapp, the proper topic can be referenced.

  


<resourceid> element's @appid attribute

john.kirkilis@...
 

The DITA 1.3 spec describes the @appid attribute of the <resourceid> as follows:
An ID used by an application to identify the topic.
While the @ux-context-string is defined as:
Contains the value of a user-assistance context-string that is used to identify the topic.
What I'm not clear about is how a UX resource, whether it be a page of a webapp or an individual field in a webform, should be represented in DITA so that when a help icon is clicked on a UX widget in a webapp, the proper topic can be referenced.


[ann][webinar] Transforming XML and HTML documents to PDF using CSS, Part 2 – Lists, Tables and Images #Oxygen

alin_belu@...
 

Hello, 
 
In the first part of the “Transforming XML and HTML documents to PDF using CSS” tutorial series, we aimed to teach you a basic understanding of the CSS layout to help you customize your PDF output. Now, you are ready to continue your journey into defining the look and format of your documents! 
 
Tomorrow (February 10), we bring you the second installment titled “Lists, Tables and Images” where Julien Lacour (software developer at Syncro Soft) will teach you more advanced CSS properties that will help you to: 
* Customize unordered and ordered lists, list-items, list bullets, etc. 
* Set table elements such as headers / footers / captions / size. 
* Display images by defining size, resolution, remote images, etc. 
* Select a particular node or set of nodes from the document with CSS combinators. 
* Create more complex elements with the ::before and ::after pseudo-elements. 
 
This is a free event and you can register at http://www.oxygenxml.com/evs2021-4.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: keep with

Chris Papademetrious
 

Hi Aaron,

If you are using the HTML5/CSS PDF transformation in Oxygen, it's pretty easy. Here is how we give authors manual control over pagination:

Making pagination controls accessible to DITA writers

You don't need to create a separate attribute for this (outputclass works fine), but I felt that doing so made it a bit more writer-friendly.

And we also do some automatic pagination handling for the writers. For example, we keep <p> introductions ending in ":" or "," with the following content, but you could easily extend this to images following procedure steps and so on (which is a good idea, actually!). Here's how we do that:

Automatically keeping introduction paragraphs with their content

We even have a Schematron check (mentioned in the preceding link's discussion) that tells writers when they've used a manual @paginate attribute in a scenario where it's automatically applied, which helps them dynamically learn the contexts in which it will be handled for them.


Hi Chris,

We use this setting to keep table rows from being split across pages:

@media print {
  *[class~='topic/row'] { page-break-inside: avoid; }
}

I put it in @media print to be pedantically correct.  :)


Re: keep with

despopoulos_chriss
 

Hi Radu...  Since we have your attention on this...  With CSS to PDF, can you avoid page breaks in a table row, but still allow the table itself to span pages?

Thanks                 cud


Re: keep with

Radu Coravu
 

Hi,

There are various properties in the CSS which control the page breaks if you are using CSS to produce PDF:

https://www.oxygenxml.com/doc/versions/23.0/ug-editor/topics/dcpp_page_breaking.html#dcpp_how_to_avoid_page_breaks_in_lists_and_tables

and combined with that Nick said, with the possibility to use a custom outputclass attribute either on the image or on its parent step you may be able to achieve what you want.

Regards,

Radu

On 2/7/21 18:15, Nicholas Mucks via groups.io wrote:
Hi Aaron,
You’ll probably want an outputclass. We do something similar with tables in PDF. The outputclass will also become a class attribute value in the CSS if you’re relying on the HTML5 plugin as your base for customizations.

For example, if a writer sets outputclass=keep-together on their table then we add keep-together.within-page to the table in the XSL-FO attributes. (It’s just a choose statement in the attribute declaration.) This then forces the table to render within one PDF page.


Take care,
- Nick

Sent from mobile

On Feb 6, 2021, at 9:58 PM, Aaron Mehl via groups.io <mehlzaidy770@...> wrote:


Hi all,
Is there a way within Dita to force an image to stay with the previous or next steps in a task?
I googled and saw ways to do this with xslt, but I was wondering if there is an attribute within Dita, or can I achieve the same thing with css.
I am using Oxygen.
Thanks,
Aaron
-- 
Radu Coravu
Oxygen XML Editor


Re: keep with

Nicholas Mucks
 

Hi Aaron,
You’ll probably want an outputclass. We do something similar with tables in PDF. The outputclass will also become a class attribute value in the CSS if you’re relying on the HTML5 plugin as your base for customizations.

For example, if a writer sets outputclass=keep-together on their table then we add keep-together.within-page to the table in the XSL-FO attributes. (It’s just a choose statement in the attribute declaration.) This then forces the table to render within one PDF page.


Take care,
- Nick

Sent from mobile

On Feb 6, 2021, at 9:58 PM, Aaron Mehl via groups.io <mehlzaidy770@...> wrote:


Hi all,
Is there a way within Dita to force an image to stay with the previous or next steps in a task?
I googled and saw ways to do this with xslt, but I was wondering if there is an attribute within Dita, or can I achieve the same thing with css.
I am using Oxygen.
Thanks,
Aaron


keep with

Aaron Mehl
 

Hi all,
Is there a way within Dita to force an image to stay with the previous or next steps in a task?
I googled and saw ways to do this with xslt, but I was wondering if there is an attribute within Dita, or can I achieve the same thing with css.
I am using Oxygen.
Thanks,
Aaron

221 - 240 of 46224