org.lwdita
org.lwdita copied to clipboard
Preserve column width when converting HTML table inside Markdown to DITA
See: https://dita-users.groups.io/g/main/message/46985
If I have a Markdown file like this:
# Changing the oil in your car
<table>
<colgroup>
<col style="width:20%">
<col style="width:80%">
</colgroup>
<thead>
<tr>
<th>Header 1</th>
<th>Header 2</th>
</tr>
</thead>
<tbody>
<tr>
<td>Column1</td>
<td>Colum12</td>
</tr>
</tbody>
</table>
referenced with format="markdown"
the DITA equivalent no longer has column specifications on the generated table.
This stylesheet "plugins/org.lwdita/xsl/hdita2dita-common.xsl" has a template matching the HTML "table" element which possibly needs to be modified to handle column spans.
While this is possible, it's unlikely that I will implement support for this.
I still hope that you change your mind on this. I've found a perfect balance using Markdown with DITA. The only thing that's holding me back from migrating to this model is the inability to set the column width with Markdown for PDFs. The only reason I'm using HTML for tables are you can have multiple paragraphs in a table cell (which is often the case). I can also use conditional processing in HTML tables.
@jelovirt if @cbgarcia18 were to try to modify the plugin to add this support where would that need to be done? I suggested this place but I did not test: https://github.com/jelovirt/org.lwdita/issues/110#issuecomment-1220242514
This feature is also needed for our R&D Markdown content where Markdown itself doesn't allow for width percentages.
Would it basically be similar to something like this quick-and-dirty test on the content above, but using XSLT instead? I assume that there'd need to be more to make it production worthy.
let
$columns := //table/colgroup/col,
$col-count := max((descendant::tr/count(*), count($columns)))
return
for $colnum in 1 to $col-count
return
let
$htmlstyle := $columns[$colnum]/@style,
$htmlcolwidth := normalize-space(substring-after($htmlstyle, 'width:')),
$calswidth := replace($htmlcolwidth,'%','*')
return
if ($htmlcolwidth eq '')
then
'<colspec class="- topic/colspec " colname="col' || $colnum || '"/>'
else
'<colspec class="- topic/colspec " colname="col' || $colnum || '" colwidth="' || $calswidth || '"/>'
output was:
<colspec class="- topic/colspec " colname="col1" colwidth="20*"/>
<colspec class="- topic/colspec " colname="col2" colwidth="80*"/>
Would it basically be similar to something like this quick-and-dirty test on the content above, but using XSLT instead? I assume that there'd need to be more to make it production worthy.
let $columns := //table/colgroup/col, $col-count := max((descendant::tr/count(*), count($columns))) return for $colnum in 1 to $col-count return let $htmlstyle := $columns[$colnum]/@style, $htmlcolwidth := normalize-space(substring-after($htmlstyle, 'width:')), $calswidth := replace($htmlcolwidth,'%','*') return if ($htmlcolwidth eq '') then '<colspec class="- topic/colspec " colname="col' || $colnum || '"/>' else '<colspec class="- topic/colspec " colname="col' || $colnum || '" colwidth="' || $calswidth || '"/>'
output was:
<colspec class="- topic/colspec " colname="col1" colwidth="20*"/> <colspec class="- topic/colspec " colname="col2" colwidth="80*"/>
Can you code it in XSLT so I can use it?
@cbgarcia18, I would if a had the time, but we've got other things going on this week. There's a big gap between proof of concept that makes a lot of assumptions about the input data and something that's production worthy. I'd want to make sure that there weren't any potential HTML col width values that would cause problems and that each table was processed separately if several tables were in a single Markdown file. I did do a test of changing one of the HTML style properties from "width" to "fred" and it didn't inject a colwidth attribute. However, it would also need to consider if the other width unit possibilities (absolute widths) should be converted to absolute DITA colwidth values. We also usually write XSpec unit tests for anything we do, and that can often take more time than the actual functional code itself to test how it handles various input scenarios. I'm more rusty with XSL than pure XPath currently, but it should be pretty simple for someone to translate. Since what I provided above can be inserted as is into an xsl:value-of select attribute, it shouldn't be to difficult to tweak it to work in XSL. We should be able to do so a month or two from now ourselves, unless someone else steps up before then.
Thanks @jelovirt 👍
Thank you @jelovirt and @raducoravu !