t-vim xhtml driver code blocks typeset on single line

[hernot]

Another issue i like to look into is the following
when running in standard mode with backend set to pdf and export to false syntax highlighting works as expected especially with my suggested improvements (issue #29) which i submitted a pull request (#30) for intial review and further discussion.

As want to publish my document also as epub i have setup mode switching where in the epub mode the backend is set to xhtml and export to yes (\setupbackend[export=yes,xhtml=yes]) among others.
When xhtml output is active the line-breaks at the end of each syntax line are lost. All code is typeset/displayed on one long single line.

My questions for a start is, where would I have to look into the t-vim, t-filter syntax highlighting code to for a hook to insert appropriate xhtml/xml line endings when xhtml/xml output is active. Where else besides the t-vim, t-filter code i would have to take a look at? What additional documentation would you suggest to take a look at etc?

As far as i have time (currently not to little) i would take a look into this improvement/fixup my self and if i manage come up with as suggestion by creating a pull request for review and further discussion if you agree.

[adityam]

The simplest way to get this to work is tagging. I had looked at it at the very beginning (see #3 ; but that is more of a reminder to myself with no details) but my attempts to get tagging to work failed. A lot has changed since then, so it is certainly worth visiting this again.

My understanding of the export mechanism is the following. Once we add tags to any macro (IIRC, it used to \starttagged[name]...\stoptagged, but I need to check again), then export translates that environment to <name> ... </name>. The rest (getting linebreaks, highlighting, etc) is simply a matter of adding appropriate CSS code.

[hernot]

Hm i couldn't withstand, i was too curious. I have checked documentation and also my first epub output (produced by context MKIV). And exempt the Tags for \SYNBOL and \SYNEOL all other Tags are already mapped to <div> </div> properly inside the xhtml. So to get the lines explicitly it should be sufficient to define appropritate TeX macros for \SYNBOL and \SYNEOL for the case where linenumbering is not active and extend the ones for linenumbering accordingly to get the tags (guess \dostarttagged and \dostoptagged do the magic) expressed inside the xhtml. And than as you say it should be just a matter of css to make the corresponding <div class="syntax line"> </div> standout as indiviual lines.

Alternatively it should also be possible to simply map \SYNBOL and \SYNEOL to a special syntaxgroup called eg "syntax code line" or similar. Than it would only be necessary to call startsyntaxgroup and stopsyntaxgroup from the linenumbering enabled macros. Would that be an option to keep things as simple and minimal as possible or do you see any comlications and flaws with this approach?

[hernot]

What i think i have figured is that things have changed less than you expect. The two macros which seem to me to do the magick are \dostarttagged and \dostoptagged. The two you have already in the \syntaxgroup and \syntaxhighlighting macros, which seem to be the reason why these already appear as tag in the xhtml output as expected. The only ones which do not appear are \SYNBOL and \SYNEOL which are either mapped to \donothing in case line numbering is off or to syntaxhighlighting_begin_number_lines and \syntaxhighlighting_end_number_lines which do not call \dostarttagged and \dostoptagged.

If you would not mind i would create a new feature branch from dev and try to get the \SYNEOL and \SYNBOL macros also call on MKIV call the \dostarttagged and \dostoptagged macros and add to the templates.css the appropriate classdefinition.
In case i would be successufl i would than create agaion a pullrequest for review. Would that be OK for you?

[adityam]

Yes, that would be wonderful!

…

On Apr 4, 2020, 7:10 AM, at 7:10 AM, hernot ***@***.***> wrote: What i think have figured is that things have changed less than you expect. The two macros which seem to do the magich are `\dostarttagged` and `\dostoptagges`. The two you have already in the `\syntaxgroup` and `\syntaxhighlighting` macros, which seem to be the reason why these already appear as tag in the xhtml output as expected. The only ones which do not appear are `\SYNBOL` and `\SYNEOL` which are either mapped to `\donothing` in case linenumbering is off or to `syntaxhighlighting_begin_number_lines` and `\syntaxhighlighting_begin_number_lines` which do not call `\dostarttagged` and `\dostoptagged`. If you would not mind i would create a new feature branch from dev and try to get the `\SYNEOL` and `\SYNBOL` macros also call on `MKIV` call the `\dostarttagged` and `\dostoptagged` macros and add to the templates.css the appropriate classdefinition. In case i would be successufl i would than create agaion a pullrequest for review. Would that be OK for you? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #31 (comment)

[hernot]

Giving up.
Managed to get the individual codelines to be individual lines. No colours. Linenumbers on separate empty lines as for typing environment too.
The backend xml/xhtml exporter seems to be still rather rudimentary, proof of concept. Way too many things hardcoded in lua. No chance to hook into it to adjust output accoriding to t-vim typesetting logic (see may mails on context mailing list).
Do you think it would make sense to repost the whole on the ConTeX development list? Or is that just for direct context development

EDIT/UPDATE

Dunno how but i managed to make it work. Space and linenumbering is now displayed as expected if css is tuned a bit. Currently working on generation and linking of css into export. May tage another set of weeks ;-)

Edit/UPDATE

First suggestion see pullrequest #34

[hernot]

I think that we got quite far in solving with #34 and #38. Besides the therein identified issues with whitespace removal when typset inside floats and using numberlocation values other than default or left this issue can be considered sort of solved or at least as mostly addressed and handled.

[adityam]

Closed by 20544c1