RE: Re the GitHub issue

Oh dear, I have to apologize, Kris! I saw the cancellation note and assumed it referred to yesterday’s meeting. I should better *read* it.

Now, from my limited experience I cannot make a statement, whether effect and usage of @placement have been discussed before. Which is why I had put it on the (yet unwritten, unsent) agenda for next Monday. Whoever has an answer to that question raised below or could remember any discussion on this, feel free to chime in.

I can only see that a related issue to handling @placement has been filed as https://github.com/jelovirt/org.lwdita/issues/87, but regarding the conversion to HTML 5. This has not yet been addressed by Jarno, but he reported to have worked on the LwDITA plugin recently.

In the spec, a behavior has been described for XDITA, but not for HDITA/MDITA so far. For XDITA, the default is to treat an <image> as inline-level element, only if part of <fig> it is to be treated as block-level element, However, no mention of @placement here. (Haven’t checked the grammar files yet…)

So, there is a gap in the spec here, and since Jarno implements, whatever the spec tells him, we should fill that gap. I can check actual behavior in sample data until next Monday and then we should talk about it.

From: dita-lightweight-dita@lists.oasis-open.org <dita-lightweight-dita@lists.oasis-open.org> On Behalf Of kris eberleinconsulting.com
Sent: Wednesday, April 20, 2022 16:11
To: dita-lightweight-dita@lists.oasis-open.org
Subject: [dita-lightweight-dita] Re the GitHub issue

We discussed this at yesterday’s TC meeting – we missed you, Frank! I asked whether anyone knew whether this had been discussed as part of LwDITA design, but no one present knew.

Our general consensus was the following:

The default value for the @placement attribute is inline, so it looks as if this DITA-OT plug-in is incorrectly handling LwDITA.
Folks authoring LwDITA content can always get the effect of placement=”break” by enclosing an image in a element.

FYI – Just as we religiously respond to comments that come through the DITA comment list, I think we also need to respond to folks who attempt to communicate with the TC using GitHub issues. I’ve added response to the GitHub issue, but did not close it.

Best,

Kris

From: dita-lightweight-dita@lists.oasis-open.org <dita-lightweight-dita@lists.oasis-open.org> On Behalf Of kris eberleinconsulting.com
Sent: Monday, April 11, 2022 10:39 AM
To: dita <dita@lists.oasis-open.org>
Cc: dita-lightweight-dita@lists.oasis-open.org
Subject: [dita-lightweight-dita] FW: [oasis-tcs/dita-lwdita] Cannot create inline graphics in HTML5 output (Issue #60)

FYI.

Kris

From: DTC-tobin <notifications@github.com>
Sent: Monday, April 11, 2022 12:22 AM
To: oasis-tcs/dita-lwdita <dita-lwdita@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: [oasis-tcs/dita-lwdita] Cannot create inline graphics in HTML5 output (Issue #60)

Due to the limitations on LwDITA, every <image> element includes a trailing   element when the data is converted to HTML5 such as follows:

DITA source

The system has a malfunction. <image href="" height="29.000pt" width="42.999pt" /> (warning indicator: Yellow)

HTML5 output

The system has a malfunction. <img class="image" height="39" src="" width="57"> (warning indicator: Yellow)

It looks like this is due to no support for the @placement attribute in LwDITA. In the dita2html5 plugin, there is the following transformation in topic.xsl (lines 1375 and 1376 in the Git repository):


<xsl:if test="not(@placement = 'inline')"> </xsl:if>

Since there is no @placement attribute, this condition can never be true, and all images are rendered with a line break after essentially making inline images impossible.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <oasis-tcs/dita-lwdita/issues/60@github.com>

dita-lightweight-dita message

DITA source

HTML5 output