xhtml export internal command \dostarttaging modify display and other XML/XHTML attributes

newer
Geometric math symbols in Lucida OT

Christoph Hintermüller

5 Apr 2020 5 Apr '20

7:56 a.m.

Hi I'm helping to make t-vim module fully usable in xhtml and futher epub export. Getting a distingct tag for the individual lines was quiet easy to do using \dostarttagged and \dostoptagged internal macros. What i'm not able to figure are the following things: 1) How can i set/modify the display attribute of the resulting div.myclass section in the generated *_templates.css file. Per default the display attribute is set to "inline" while i need "block" or "flex" (not jet decided" which). 2) How can i predefine the white-space css attribute to pre-wrap 3) Is there a way to tell context to include the resulting class inside the *.default.css or *.styles.css or should that be done via the css parameter of the \setupbackend macro only? Best Xristoph

Show replies by date

Christoph Hintermüller

8 Apr 8 Apr

3:52 a.m.

Hi On Sun, 2020-04-05 at 15:56 +0200, Christoph Hintermüller wrote:

...

Hi I'm helping to make t-vim module fully usable in xhtml and futher epub export. Getting a distingct tag for the individual lines was quiet easy to do using \dostarttagged and \dostoptagged internal macros. What i'm not able to figure are the following things: 1) How can i set/modify the display attribute of the resulting div.myclass section in the generated *_templates.css file. Per default the display attribute is set to "inline" while i need "block" or "flex" (not jet decided" which). 2) How can i predefine the white-space css attribute to pre-wrap 3) Is there a way to tell context to include the resulting class inside the *.default.css or *.styles.css or should that be done via the css parameter of the \setupbackend macro only?

I figured so far that with the command \setelementnature[<mytagid>][block] I can change the css 'displayÄ attribute of my <mytag> to display=block in the *_templates.css output But i did not manage so far to in addition set the 'white-space' css attribute of mytag to 'pre-wrap' I tried `\dosettagproperty` and `\setelementexporttag` commands but none of the gave me the expected result in the *_templates.css output for the xhtm export. What other commands do i have to call first, after `\dostarttagged` to be able to use eg `dosettagproperty` to also set the 'white-space' css attribute accordingly and/or how is the related context/lua property called which will be than translated into `white-space=pre-wrap`. The css 'display' attribute is to be changed by changing the 'nature' property of the tag. Is there anybody who can provide at least some hints which *.tex and *.lua source files to look at to figure myself. At least some orientation would already help. Best Xristoph

Christoph Hintermüller

10 Apr 10 Apr

6:49 a.m.

Hi again On Wed, 2020-04-08 at 11:52 +0200, Christoph Hintermüller wrote:

...

I figured so far that with the command \setelementnature[<mytagid>][block]

I can change the css 'displayÄ attribute of my <mytag> to display=block in the *_templates.css output

But i did not manage so far to in addition set the 'white-space' css attribute of mytag to 'pre-wrap'

I tried `\dosettagproperty` and `\setelementexporttag` commands but none of the gave me the expected result in the *_templates.css output for the xhtm export.

What other commands do i have to call first, after `\dostarttagged` to be able to use eg `dosettagproperty` to also set the 'white-space' css attribute accordingly and/or how is the related context/lua property called which will be than translated into `white-space=pre-wrap`. The css 'display' attribute is to be changed by changing the 'nature' property of the tag.

Is there anybody who can provide at least some hints which *.tex and *.lua source files to look at to figure myself. At least some orientation would already help.

Nope there isn't most of the stuff is hardcoded into the backend expoerter lua. Including template for custome css template which only considers display (nature) settings. And spaces are striped in any case. All in all the backend exporter seems up to now still handcrafted experimental proof of concept. Which makes me quenstion my self why did i switch from latex to context. The major and killer reason was single source multiple formats. But the only fully functional format so far is pdf/dvi/ps xhtml/xml/epub are only working for core stuff. All the nice modules seem not to be supported at all by backend exporter. Please increase the USB of ConTeXt by improoving the xml/xhtml exporter backend by allowing modules to hook into it, defining how the contotent should be processed and what css attributes the corresponding tags should receive. Second i noticed that even in verbatim the line numbers are not on the line they number but are, due to late injections printed on an empty line in xhtml. Needs improvement here too. All the above and some more forces me to push my plans to publish my lecture notes on programming as pdf and epub to likely next year. And helping in Improvement is for now not an option too me for now, exempt maybe lateron in testing. Happy Easter. Xristoph

Thomas A. Schmitz

7:09 a.m.

...

On 10. Apr 2020, at 14:49, Christoph Hintermüller wrote:

Please increase the USB of ConTeXt by improoving the xml/xhtml exporter backend by allowing modules to hook into it, defining how the contotent should be processed and what css attributes the corresponding tags should receive.

Second i noticed that even in verbatim the line numbers are not on the line they number but are, due to late injections printed on an empty line in xhtml. Needs improvement here too.

All the above and some more forces me to push my plans to publish my lecture notes on programming as pdf and epub to likely next year. And helping in Improvement is for now not an option too me for now, exempt maybe lateron in testing.

Happy Easter.

What, precisely, was the point of this long message? Thomas

Hans Hagen

8:29 a.m.

On 4/10/2020 3:09 PM, Thomas A. Schmitz wrote:

...

...
On 10. Apr 2020, at 14:49, Christoph Hintermüller wrote:

Please increase the USB of ConTeXt by improoving the xml/xhtml exporter backend by allowing modules to hook into it, defining how the contotent should be processed and what css attributes the corresponding tags should receive.

Second i noticed that even in verbatim the line numbers are not on the line they number but are, due to late injections printed on an empty line in xhtml. Needs improvement here too.

All the above and some more forces me to push my plans to publish my lecture notes on programming as pdf and epub to likely next year. And helping in Improvement is for now not an option too me for now, exempt maybe lateron in testing.

Happy Easter.

What, precisely, was the point of this long message?

Indeed. the exporter is just a reconstructor of content so the better structured, the better the export, and the trickier the rendering the worse. Also, one can if needed add tags, add attributes etc etc but don't expect me to keep track of all modules and user stuff and add export specififcs. Of course I can make some aspects better but i never needed epub so far. Then, given an export, one can use xslt or whatever, of have one's own css as there is no common ground for rendering idiologies. Ever yuser wants something different. That said: the best multi-output stuff comes from good neutral input and for instance xml is more suitable for that than tex encoded input. I'm currently doing just that: making some css for rather extensive kind of free xml based content (mostly because i have nothing better todo right now). In the end it all boils down to 'does it pay off' in terms of 'useability', 'neccessity' and 'the fun of it'. We're talking of free software so no one can demand something, only request. Suggestion for Christoph: look at what Thomas has done for a long time now: one input (often quite advanced) and multiple output for publishing ane educational purposes. And it looks pretty good too. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Christoph Hintermüller

10:11 a.m.

On Fri, 2020-04-10 at 16:29 +0200, Hans Hagen wrote:

...

On 4/10/2020 3:09 PM, Thomas A. Schmitz wrote:

...
...
On 10. Apr 2020, at 14:49, Christoph Hintermüller < christoph@out-world.com> wrote:

Indeed. the exporter is just a reconstructor of content so the better structured, the better the export, and the trickier the rendering the worse. Also, one can if needed add tags, add attributes etc etc but don't expect me to keep track of all modules and user stuff and add export specififcs. Of course I can make some aspects better but i never needed epub so far.

There is no need to keep track, otherwise the modules and user stuff would be senseless. It is up to them to keep track of their specialities.

...

Then, given an export, one can use xslt or whatever, of have one's own css as there is no common ground for rendering idiologies. Ever yuser wants something different. he best multi-output stuff comes from good neutral input and for instance xml is more suitable for that than tex encoded input. I'm currently doing just that: making some css for rather extensive kind of free xml based content (mostly because i have nothing better todo right now).

If the xml is the document source, what for would I need ConTeXt at all? Why not use typesetting system using xml as native format?

...

In the end it all boils down to 'does it pay off' in terms of 'useability', 'neccessity' and 'the fun of it'. We're talking of free software so no one can demand something, only request.

I apologize if if missed the proper tone. It was just my frustration, that any attempt to convince the exporter that it should display spaces as are in the inputfile and not remove them. The pdf backend properly keeps it like in typing environment. And the second which increased my frustration more and what i could also not solve by css is that when linenumbers are added later they appear on separate lines and not on the same line as in the pdf output. That is also true for typing environment (see attached) example. Sorry again.

...

Suggestion for Christoph: look at what Thomas has done for a long time now: one input (often quite advanced) and multiple output for publishing ane educational purposes. And it looks pretty good too.

Thank you very much i will do. You are refering to Thomas Schmitz?

Christoph Hintermüller

3:26 p.m.

Hi Hands, Hi Thomas Thank you again for your direct and open answers. After some hours working off my despair physically. I somehow managed, after days of struggling and not seeing the most obvious to get to the expected point. I can not fully explain how and why but so far it seems to work for pdf and xhtml output now. And the css i also will get right now I'm optimistic again. Best Xristoph

1559

Age (days ago)

1564

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

Christoph Hintermüller
Hans Hagen
Thomas A. Schmitz