Plain TeX writer

Plain TeX writer

[Vít Novotný]

[-- Attachment #1.1: Type: text/plain, Size: 5029 bytes --]



In pull request #1541 <https://github.com/jgm/pandoc/issues/1541>, John 
MacFarlane floated the idea of having a Pandoc writer whose output could be 
“processed by plain tex (or perhaps eplain), without latex or context 
macros.” In their proof of concept 
<https://github.com/drehak/pandoc-to-markdown>, Dominik Rehák 
<https://github.com/drehak> explores what this would look like in practice. 

Dominik’s proof of concept contains a custom Lua writer 
pandoc-to-markdown.lua that you can use as follows: 


*$ cat > example.md*Under his pillow P'raps found  
~~A cake that weighed a half a pound.~~  
A plenty of space to roll around.

 $ pandoc -i example.md -f pandoc-to-markdown.lua -o example.tex

*$ cat example.tex*\pandocDocumentBegin
Under\pandocSpace{}his\pandocSpace{}pillow\pandocSpace{}P’raps\pandocSpace{}found\pandocLineBreak
\pandocStrikeout{A\pandocSpace{}cake\pandocSpace{}that\pandocSpace{}weighed\pandocSpace{}a\pandocSpace{}half\pandocSpace{}a\pandocSpace{}pound.}\pandocLineBreak
A\pandocSpace{}plenty\pandocSpace{}of\pandocSpace{}space\pandocSpace{}to\pandocSpace{}roll\pandocSpace{}around.
\pandocDocumentEnd

To typeset the example document, you can use a macro package that defines 
how the various \pandoc... commands should be formatted. For LaTeX, the 
proof of concept contains the pandoc-to-markdown.sty style file that you 
can use as follows: 


*$ cat > example.ltx*\documentclass{article}
\usepackage{pandoc-to-markdown}
\begin{document}
\input example.tex
\end{document} 

$ pdflatex example.ltx

Here is the output document example.pdf:

 [image: example.png]

The proof-of-concept contains many more examples for you to try out in the 
examples/ directory 
<https://github.com/drehak/pandoc-to-markdown/tree/main/examples>.

Dominik's work is part of their bachelor's thesis, which is to appear this 
fall. Dominik has already published two articles about their work in 
hobbyist journals: the CSTUG Bulletin 31:1–4 
<https://www.cstug.cz/bulletin/pdf/2021-1-4.pdf#page=85> (in Slovak, see a 
machine translation to English 
<https://translate.google.com/translate?sl=auto&tl=en&u=https://www.fi.muni.cz/~xnovot32/bulletin/2021-1-4/06-rehak-pandoc/&client=webapp>) 
and in TUGboat 43:1 
<https://www.tug.org/TUGboat/tb43-1/tb133novotny-markdown.pdf#page=3> (see 
Section 2.3). The implementation rests on my Markdown package for TeX 
<https://ctan.org/pkg/markdown>, which provides formatting for most 
elements of the Pandoc AST across different TeX formats such as plain TeX, 
LaTeX, and ConTeXt. 

Here are some limitations of the proof of concept:

   - 
   
   For the sake of convenience, some of the \pandoc... commands that we 
   produce are in a form that closely mimics the commands provided by the 
   Markdown package rather than Pandoc’s AST. For example, the \pandocCode, 
   \pandocLink, and \pandocHeader commands discard attributes, the 
   \pandocImage and \pandocCaptionedImage commands receive parameters with 
   TeX’s special characters escaped in a way required by the Markdown package, 
   and the LineBlock element of Pandoc’s AST is simulated by a series of 
   \pandocLineBreak commands.
   
   In the future, we would like to make the  \pandoc... commands closer to 
   the Pandoc’s AST, so that a lossless round trip from AST to TeX and back is 
   possible. In TeX, we can process text using regular expressions (see the 
   l3regex module of the expl3 macro package 
   <https://www.ctan.org/pkg/l3kernel>), which allows us to move most 
   parameter preprocessing code from our Lua writer to the definitions of the 
   \pandoc… commands.
   - 
   
   The custom Lua writer pandoc-to-markdown.lua uses the old-style custom 
   Lua writer API that will no longer be supported in Pandoc 3.0.0. We would 
   like to rewrite the custom Lua write to Haskell, so that it can become an 
   integral part of Pandoc independent of Pandoc’s Lua API.
   
   In the future, the ConTeXt and LaTeX writers of Pandoc could be replaced 
   by a single writer that would produce format-agnostic TeX code. Formatting 
   for the TeX code would then be provided by format-specific TeX macro 
   packages such as the pandoc-to-markdown.sty style file for LaTeX. This 
   approach will reduce the amount of code maintained by Pandoc and increase 
   the number of supported TeX formats, which is a win-win for both Pandoc 
   maintainers and Pandoc users. Both Dominik and I would be happy to discuss 
   with you how to best get there.
   

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/51539828-c876-437b-bb1e-a5efcf752762n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 7204 bytes --]

[-- Attachment #2: example.png --]
[-- Type: image/png, Size: 30143 bytes --]

Re: Plain TeX writer

[John MacFarlane]

I like the idea of including a plain TeX writer in pandoc, and these Lua experiments will be helpful.  (Btw, when we go to 3.0, modifying the old-style Lua writer to work as a new-style writer will only take a line or two of code.)

What would you think about replacing \pandocSpace with a regular space character? IT would make the output a lot more readable.  Similarly, SoftBreak could be a regular newline character.

It would be nice to see some examples involving arguments and attributes, e.g. links and headers.

Why is the package called "pandoc-to-markdown"?  That would lead me to expect that it produces markdown output.

John

> On Oct 19, 2022, at 6:59 AM, Vít Novotný <witiko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> In pull request #1541, John MacFarlane floated the idea of having a Pandoc writer whose output could be “processed by plain tex (or perhaps eplain), without latex or context macros.” In their proof of concept, Dominik Rehák explores what this would look like in practice. 
> 
> Dominik’s proof of concept contains a custom Lua writer pandoc-to-markdown.lua that you can use as follows: 
> 
> $ cat > example.md
> Under his pillow P'raps found  
> ~~A cake that weighed a half a pound.~~  
> A plenty of space to roll around.
> 
>  $ pandoc -i example.md -f pandoc-to-markdown.lua -o example.tex
> $ cat example.tex
> \pandocDocumentBegin
> Under\pandocSpace{}his\pandocSpace{}pillow\pandocSpace{}P’raps\pandocSpace{}found\pandocLineBreak
> \pandocStrikeout{A\pandocSpace{}cake\pandocSpace{}that\pandocSpace{}weighed\pandocSpace{}a\pandocSpace{}half\pandocSpace{}a\pandocSpace{}pound.}\pandocLineBreak
> A\pandocSpace{}plenty\pandocSpace{}of\pandocSpace{}space\pandocSpace{}to\pandocSpace{}roll\pandocSpace{}around.
> \pandocDocumentEnd
> 
> To typeset the example document, you can use a macro package that defines how the various \pandoc... commands should be formatted. For LaTeX, the proof of concept contains the pandoc-to-markdown.sty style file that you can use as follows: 
> 
> $ cat > example.ltx
> \documentclass{article}
> \usepackage{pandoc-to-markdown}
> \begin{document}
> \input example.tex
> \end{document} 
> 
> $ pdflatex example.ltx
> 
> Here is the output document example.pdf:
> 
>  <example.png>
> 
> The proof-of-concept contains many more examples for you to try out in the examples/ directory.
> 
> Dominik's work is part of their bachelor's thesis, which is to appear this fall. Dominik has already published two articles about their work in hobbyist journals: the CSTUG Bulletin 31:1–4 (in Slovak, see a machine translation to English) and in TUGboat 43:1 (see Section 2.3). The implementation rests on my Markdown package for TeX, which provides formatting for most elements of the Pandoc AST across different TeX formats such as plain TeX, LaTeX, and ConTeXt. 
> 
> Here are some limitations of the proof of concept:
> 
> 	• For the sake of convenience, some of the \pandoc... commands that we produce are in a form that closely mimics the commands provided by the Markdown package rather than Pandoc’s AST. For example, the \pandocCode, \pandocLink, and \pandocHeader commands discard attributes, the \pandocImage and \pandocCaptionedImage commands receive parameters with TeX’s special characters escaped in a way required by the Markdown package, and the LineBlock element of Pandoc’s AST is simulated by a series of \pandocLineBreak commands.
> 
> In the future, we would like to make the  \pandoc... commands closer to the Pandoc’s AST, so that a lossless round trip from AST to TeX and back is possible. In TeX, we can process text using regular expressions (see the l3regex module of the expl3 macro package), which allows us to move most parameter preprocessing code from our Lua writer to the definitions of the \pandoc… commands.
> 
> 	• The custom Lua writer pandoc-to-markdown.lua uses the old-style custom Lua writer API that will no longer be supported in Pandoc 3.0.0. We would like to rewrite the custom Lua write to Haskell, so that it can become an integral part of Pandoc independent of Pandoc’s Lua API.
> 
> In the future, the ConTeXt and LaTeX writers of Pandoc could be replaced by a single writer that would produce format-agnostic TeX code. Formatting for the TeX code would then be provided by format-specific TeX macro packages such as the pandoc-to-markdown.sty style file for LaTeX. This approach will reduce the amount of code maintained by Pandoc and increase the number of supported TeX formats, which is a win-win for both Pandoc maintainers and Pandoc users. Both Dominik and I would be happy to discuss with you how to best get there.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/51539828-c876-437b-bb1e-a5efcf752762n%40googlegroups.com.
> <example.png>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/84C142C7-20EF-411E-AF94-D0AA008FA9DA%40gmail.com.

Re: Plain TeX writer

[Vít Novotný]

[-- Attachment #1.1: Type: text/plain, Size: 2111 bytes --]

Dne středa 19. října 2022 v 17:43:31 UTC+2 uživatel fiddlosopher napsal:

> What would you think about replacing \pandocSpace with a regular space 
> character? IT would make the output a lot more readable. Similarly, 
> SoftBreak could be a regular newline character.
>

The input processor of TeX will fold one or more spaces into a single space 
and consume all spaces at the end of a line. Making spaces and soft breaks 
into commands avoids this at the cost of lesser readability.
 

> It would be nice to see some examples involving arguments and attributes, 
> e.g. links and headers.
>

As stated in my original post, attributes are currently discarded by the 
writer. However, the Markdown package supports attributes on headers 
<https://witiko.github.io/markdown/#header-attributes> and attributes on 
divs and spans <https://github.com/Witiko/markdown/issues/126>, links, 
images, and inline code <https://github.com/Witiko/markdown/issues/123> as 
well as raw attributes <https://github.com/Witiko/markdown/issues/173> are 
planned for the next release (2.18.0). Therefore, adding support for 
attributes on many types of elements should be straightforward.
 

> Why is the package called "pandoc-to-markdown"? That would lead me to 
> expect that it produces markdown output.
>

The implementation rests on my Markdown package for TeX 
<https://ctan.org/pkg/markdown>, which provides formatting for most 
elements of the Pandoc AST across different TeX formats such as plain TeX, 
LaTeX, and ConTeXt. Dominik's proof of concept bridges Pandoc with the 
Markdown package and hence the (somewhat confusing) name.
 

> John
>

Best,
Vit 

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/5e9dfe75-ea0e-4287-a6a0-47842700f292n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3189 bytes --]

Re: Plain TeX writer

[Bastien DUMONT]

That looks very promising. I contemplated to write such a filter to be able to define my own stylesheet more flexibly and possibly to work with other TeX formats, so thank you both for having undertaken this task. Some personal thoughts follow.

I don't understand either the rationale for \pandocSpace and \pandocLinebreak. Since Markdown and TeX agree on handling simple line breaks and repeated spaces like single spaces, in what cases would it be useful?

As for spans and divs, why not generate macros according to their classes? It would only require defining in the header which attributes are related to which classes. For instance:

```md
---
classes:
- term:
  - lem
- def:
  - lem
  - domain
---

[Pandoc]{.term .def lem="pandoc" domain="software"} is a Haskell library for converting
from one markup format to another, and a command-line tool that uses this library.

[Pandoc]{.term lem="pandoc"} can convert between numerous markup and word processing formats,
including, but not limited to, various flavors of Markdown, HTML, LaTeX and Word docx.
```

would be converted to (stripping the markup for spaces and soft line breaks):

```tex
\pandocSpTerm[lem=pandoc]{\pandocSpDef[lem=pandoc, domain=software]{Pandoc}}
is a Haskell library for converting from one markup format to another, and
a command-line tool that uses this library.

\pandocSpTerm[lem=pandoc]{Pandoc} can convert between numerous markup
and word processing formats, including, but not limited to, various
flavors of Markdown, HTML, LaTeX and Word docx.
```

Thanks to the package xkeyval, the key-value argument could be handled quite easily in all formats that include Plain TeX.

Le Wednesday 19 October 2022 à 09:21:09AM, Vít Novotný a écrit :
> Dne středa 19. října 2022 v 17:43:31 UTC+2 uživatel fiddlosopher napsal:
> 
>     What would you think about replacing \pandocSpace with a regular space
>     character? IT would make the output a lot more readable. Similarly,
>     SoftBreak could be a regular newline character.
> 
> 
> The input processor of TeX will fold one or more spaces into a single space and
> consume all spaces at the end of a line. Making spaces and soft breaks into
> commands avoids this at the cost of lesser readability.
>  
> 
>     It would be nice to see some examples involving arguments and attributes,
>     e.g. links and headers.
> 
> 
> As stated in my original post, attributes are currently discarded by the
> writer. However, the Markdown package supports [1]attributes on headers and [2]
> attributes on divs and spans, [3]links, images, and inline code as well as [4]
> raw attributes are planned for the next release (2.18.0). Therefore, adding
> support for attributes on many types of elements should be straightforward.
>  
> 
>     Why is the package called "pandoc-to-markdown"? That would lead me to
>     expect that it produces markdown output.
> 
> 
> The implementation rests on [5]my Markdown package for TeX, which provides
> formatting for most elements of the Pandoc AST across different TeX formats
> such as plain TeX, LaTeX, and ConTeXt. Dominik's proof of concept bridges
> Pandoc with the Markdown package and hence the (somewhat confusing) name.
>  
> 
>     John
> 
> 
> Best,
> Vit 
> 
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to [6]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit [7]https://groups.google.com/d/msgid/
> pandoc-discuss/5e9dfe75-ea0e-4287-a6a0-47842700f292n%40googlegroups.com.
> 
> References:
> 
> [1] https://witiko.github.io/markdown/#header-attributes
> [2] https://github.com/Witiko/markdown/issues/126
> [3] https://github.com/Witiko/markdown/issues/123
> [4] https://github.com/Witiko/markdown/issues/173
> [5] https://ctan.org/pkg/markdown
> [6] mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
> [7] https://groups.google.com/d/msgid/pandoc-discuss/5e9dfe75-ea0e-4287-a6a0-47842700f292n%40googlegroups.com?utm_medium=email&utm_source=footer

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/Y1EBU0Ch0HHr2geB%40localhost.

Re: Plain TeX writer

[Vít Novotný]

[-- Attachment #1.1: Type: text/plain, Size: 1921 bytes --]

Dne čtvrtek 20. října 2022 v 10:06:23 UTC+2 uživatel Bastien Dumont napsal:

> I don't understand either the rationale for \pandocSpace and 
> \pandocLinebreak. Since Markdown and TeX agree on handling simple line 
> breaks and repeated spaces like single spaces, in what cases would it be 
> useful?


I was going to give an example of a Word document with the text 
*Hello␣␣␣world!* and show that it would produce the output *Hello 
\pandocSpace{}\pandocSpace{}\pandocSpace{}world!*, which would allow us to 
preserve the repeated spaces. Howover, running *pandoc -i example.docx -t 
pandoc-to-markdown.lua* produces *Hello\pandocSpace{}world!* as the output. 
This indicates that not only Markdown and TeX fold repeated spaces, but 
Pandoc's AST in general does. In that case, it seems reasonable to replace 
*\pandocSpace{}* with *␣* and *\pandocLineBreak{}* with *⤶* in the TeX 
output as John also suggested.

Thanks to the package xkeyval, the key-value argument could be handled 
> quite easily in all formats that include Plain TeX.
>

The xkeyval package is one option. I am partial to the expl3 programming 
language <https://www.ctan.org/pkg/l3kernel> from the LaTeX3 project, which 
provides many programming extensions to TeX, including key--value 
interfaces (see the l3keys module in the LaTeX3 Interface Documentation 
<http://mirrors.ctan.org/macros/latex/contrib/l3kernel/interface3.pdf>). 
However, some would call the syntax of expl3 arcane.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/a7d769e7-083c-4cb9-a9a2-b5a21b62c8f0n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2693 bytes --]

Re: Plain TeX writer

[Bastien DUMONT]

> The xkeyval package is one option. I am partial to [1]the expl3 programming
> language from the LaTeX3 project, which provides many programming extensions to
> TeX, including key--value interfaces (see the l3keys module in [2]the LaTeX3
> Interface Documentation). However, some would call the syntax of expl3 arcane.

Yes, while processing the file with LaTeX, which is your use case with the Markdown package, the expl3 programming layer is surely worth considering. My point was just to say that the key-value arguments in the kind of output I propose would not hinder portability across formats, since we can at least resort to xkeyval for those that do not handle such arguments natively!

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/Y1EahFGwPIoI1E2i%40localhost.

Re: Plain TeX writer

[Vít Novotný]

[-- Attachment #1.1: Type: text/plain, Size: 1617 bytes --]

Dne čtvrtek 20. října 2022 v 11:53:14 UTC+2 uživatel Bastien Dumont napsal:

> Yes, while processing the file with LaTeX, which is your use case with the 
> Markdown package, the expl3 programming layer is surely worth considering. 
> My point was just to say that the key-value arguments in the kind of output 
> I propose would not hinder portability across formats, since we can at 
> least resort to xkeyval for those that do not handle such arguments 
> natively!


Note that you can load expl3 with *\input expl3-generic\relax* in both 
plain TeX and ConTeXt and it will just work for the most part. As the 
LaTeX3 Interface Documentation says 
<http://mirrors.ctan.org/macros/latex/contrib/l3kernel/interface3.pdf>:

> The fundamental programming code can also be loaded with other TeX 
formats, subject to restrictions on the full range of functionality. 

In my opinion, this is entirely too modest of the LaTeX team to say. I have 
used expl3 in library code that runs with both plain TeX and ConTeXt and 
all works as expected with the exception of some minor issues with the 
*l3file* module in ConTeXt (now fixed 
<https://github.com/latex3/latex3/pull/1114>).

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/782726a4-9890-4396-9696-4f5a349f9885n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2156 bytes --]

Re: Plain TeX writer

[Bastien DUMONT]

Oh, thank you for the information!

Le Thursday 20 October 2022 à 03:32:43AM, Vít Novotný a écrit :
> Dne čtvrtek 20. října 2022 v 11:53:14 UTC+2 uživatel Bastien Dumont napsal:
> 
>     Yes, while processing the file with LaTeX, which is your use case with the
>     Markdown package, the expl3 programming layer is surely worth considering.
>     My point was just to say that the key-value arguments in the kind of output
>     I propose would not hinder portability across formats, since we can at
>     least resort to xkeyval for those that do not handle such arguments
>     natively!
> 
> 
> Note that you can load expl3 with \input expl3-generic\relax in both plain TeX
> and ConTeXt and it will just work for the most part. As [1]the LaTeX3 Interface
> Documentation says:
> 
> > The fundamental programming code can also be loaded with other TeX formats,
> subject to restrictions on the full range of functionality. 
> 
> In my opinion, this is entirely too modest of the LaTeX team to say. I have
> used expl3 in library code that runs with both plain TeX and ConTeXt and all
> works as expected with the exception of some minor issues with the l3file
> module in ConTeXt ([2]now fixed).
> 
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to [3]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit [4]https://groups.google.com/d/msgid/
> pandoc-discuss/782726a4-9890-4396-9696-4f5a349f9885n%40googlegroups.com.
> 
> References:
> 
> [1] http://mirrors.ctan.org/macros/latex/contrib/l3kernel/interface3.pdf
> [2] https://github.com/latex3/latex3/pull/1114
> [3] mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
> [4] https://groups.google.com/d/msgid/pandoc-discuss/782726a4-9890-4396-9696-4f5a349f9885n%40googlegroups.com?utm_medium=email&utm_source=footer

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/Y1EmPxxlfJtHwi6c%40localhost.

Re: Plain TeX writer

[Vít Novotný]

[-- Attachment #1.1: Type: text/plain, Size: 1238 bytes --]


>
> What would you think about replacing \pandocSpace with a regular space 
> character? IT would make the output a lot more readable. Similarly, 
> SoftBreak could be a regular newline character.
>

In drehak/pandoc-to-markdown#20 
<https://github.com/drehak/pandoc-to-markdown/pull/20> and #21 
<https://github.com/drehak/pandoc-to-markdown/pull/21>, we have replaced 
*\pandocSpace* and *\pandocSoftBreak* with ␣ and *⤶*, respectively. Running 
the code from the original post will now produce the following output:


*$ cat example.tex*
*\pandocDocumentBegin*


*Under his pillow P’raps found\pandocLineBreak\pandocStrikeout{A cake that 
weighed a half a pound.}\pandocLineBreakA plenty of space to roll 
around\pandocDocumentEnd*

This is definitely easier on the eye than the original.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/24c01860-2f35-4ff0-9d31-63d10f764f79n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1852 bytes --]

Re: Plain TeX writer

[John MacFarlane]

I like the look of this better. But, just to be clear about the costs before it’s set in stone: this means that you couldn’t “reprogram” pandoc Spaces or SoftBreaks using tex macros.  So, for example, you couldn’t make Spaces appear as visible ␠ characters, and you couldn’t make SoftBreaks create hard breaks in the output.

Probably these are acceptable limitations, but I mention them just in case!

> On Oct 26, 2022, at 1:09 PM, Vít Novotný <witiko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> What would you think about replacing \pandocSpace with a regular space character? IT would make the output a lot more readable. Similarly, SoftBreak could be a regular newline character.
> 
> In drehak/pandoc-to-markdown#20 and #21, we have replaced \pandocSpace and \pandocSoftBreak with ␣ and ⤶, respectively. Running the code from the original post will now produce the following output:
> 
> $ cat example.tex
> \pandocDocumentBegin
> Under his pillow P’raps found\pandocLineBreak
> \pandocStrikeout{A cake that weighed a half a pound.}\pandocLineBreak
> A plenty of space to roll around
> \pandocDocumentEnd
> 
> This is definitely easier on the eye than the original.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/24c01860-2f35-4ff0-9d31-63d10f764f79n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/1EC34FB9-2344-40AC-91CD-22B3D9069EE6%40gmail.com.

Re: Plain TeX writer

[Bastien DUMONT]

Fortunately, it is possible by making the space and the newline characters active in TeX! (Provided that a SoftBreak is rendered as a line break in the TeX output.) This is how \obeylines and \obeyspaces work.

Le Wednesday 26 October 2022 à 05:24:36PM, John MacFarlane a écrit :
> I like the look of this better. But, just to be clear about the costs before it’s set in stone: this means that you couldn’t “reprogram” pandoc Spaces or SoftBreaks using tex macros.  So, for example, you couldn’t make Spaces appear as visible ␠ characters, and you couldn’t make SoftBreaks create hard breaks in the output.
> 
> Probably these are acceptable limitations, but I mention them just in case!
> 
> > On Oct 26, 2022, at 1:09 PM, Vít Novotný <witiko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 
> > What would you think about replacing \pandocSpace with a regular space character? IT would make the output a lot more readable. Similarly, SoftBreak could be a regular newline character.
> > 
> > In drehak/pandoc-to-markdown#20 and #21, we have replaced \pandocSpace and \pandocSoftBreak with ␣ and ⤶, respectively. Running the code from the original post will now produce the following output:
> > 
> > $ cat example.tex
> > \pandocDocumentBegin
> > Under his pillow P’raps found\pandocLineBreak
> > \pandocStrikeout{A cake that weighed a half a pound.}\pandocLineBreak
> > A plenty of space to roll around
> > \pandocDocumentEnd
> > 
> > This is definitely easier on the eye than the original.
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/24c01860-2f35-4ff0-9d31-63d10f764f79n%40googlegroups.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/1EC34FB9-2344-40AC-91CD-22B3D9069EE6%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/Y1ouG5j9V0ObqP9a%40localhost.

Re: Plain TeX writer

[John MacFarlane]

> On Oct 27, 2022, at 12:07 AM, Bastien DUMONT <bastien.dumont-VwIFZPTo/vqsTnJN9+BGXg@public.gmane.org> wrote:
> 
> Fortunately, it is possible by making the space and the newline characters active in TeX! (Provided that a SoftBreak is rendered as a line break in the TeX output.) This is how \obeylines and \obeyspaces work.

But this might not be what you want; after all there are going to be spaces in code blocks, and you might not want to treat them the same way (they do not correspond to pandoc Space elements).  There may also be line breaks in the source that don't correspond to SoftBreak.


-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/B180C2FD-5AD9-47F2-8E5D-8133CCD8CE00%40gmail.com.

Re: Plain TeX writer

[Vít Novotný]

[-- Attachment #1.1: Type: text/plain, Size: 2552 bytes --]

>  So, for example, you couldn’t make Spaces appear as visible ␠ 
characters, and you couldn’t make SoftBreaks create hard breaks in the 
output.

Replacing *\pandocSpace* with ASCII spaces makes it difficult to reprogram 
spaces on the top level of the document, but we can definitely substitute 
spaces in parameters of commands such as  *\pandocCode*, which would cover 
many (if not most) use cases.

The following example LaTeX document produces the text 
*we␣want␣visible␣spaces␣here* in a monospaced font:





















*\documentclass{standalone}\usepackage{xparse}\ExplSyntaxOn\ProvideDocumentCommand  
{ \pandocCode }  { m }  { \pandoc_code:n { #1 } }\cs_new:Nn  
\pandoc_code:n  {    \tl_set:Nn \l_tmpa_tl { #1 }    
\regex_replace_all:nnN      { \s }      { \c{textvisiblespace} }      
\l_tmpa_tl    \texttt { \l_tmpa_tl }  
}\ExplSyntaxOff\begin{document}\pandocCode{we want visible spaces 
here}\end{document}*

>  There may also be line breaks in the source that don't correspond to 
SoftBreak.

Any lines that end with a comment character (%) will skip over the newline 
character. Therefore, we can have newlines in the source code that wouldn't 
trigger the active newline character.

The following example plain TeX document produces the text *foo bar baz*:

*\catcode`\^^M=13*


*\def^^M{ bar }%foobaz%*
*\bye*

Dne čtvrtek 27. října 2022 v 19:09:30 UTC+2 uživatel fiddlosopher napsal:

>
> > On Oct 27, 2022, at 12:07 AM, Bastien DUMONT <bastien...-VwIFZPTo/vqsTnJN9+BGXg@public.gmane.org> 
> wrote:
> > 
> > Fortunately, it is possible by making the space and the newline 
> characters active in TeX! (Provided that a SoftBreak is rendered as a line 
> break in the TeX output.) This is how \obeylines and \obeyspaces work.
>
> But this might not be what you want; after all there are going to be 
> spaces in code blocks, and you might not want to treat them the same way 
> (they do not correspond to pandoc Space elements). There may also be line 
> breaks in the source that don't correspond to SoftBreak.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/9dfc8b26-3fda-4882-93b7-06d44671ef7fn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3485 bytes --]

Re: Plain TeX writer

['William Lupton' via pandoc-discuss]

[-- Attachment #1: Type: text/plain, Size: 3516 bytes --]

Would it be feasible for the https://ctan.org/pkg/markdown package to
support an option to control whether to generate ASCII space or
\pandocSpace (perhaps with a default of generation ASCII spaces)?

On Wed, 2 Nov 2022 at 14:17, Vít Novotný <witiko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> >  So, for example, you couldn’t make Spaces appear as visible ␠
> characters, and you couldn’t make SoftBreaks create hard breaks in the
> output.
>
> Replacing *\pandocSpace* with ASCII spaces makes it difficult to
> reprogram spaces on the top level of the document, but we can definitely
> substitute spaces in parameters of commands such as  *\pandocCode*, which
> would cover many (if not most) use cases.
>
> The following example LaTeX document produces the text
> *we␣want␣visible␣spaces␣here* in a monospaced font:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *\documentclass{standalone}\usepackage{xparse}\ExplSyntaxOn\ProvideDocumentCommand
> { \pandocCode }  { m }  { \pandoc_code:n { #1 } }\cs_new:Nn
> \pandoc_code:n  {    \tl_set:Nn \l_tmpa_tl { #1 }
> \regex_replace_all:nnN      { \s }      { \c{textvisiblespace} }
> \l_tmpa_tl    \texttt { \l_tmpa_tl }
> }\ExplSyntaxOff\begin{document}\pandocCode{we want visible spaces
> here}\end{document}*
>
> >  There may also be line breaks in the source that don't correspond to
> SoftBreak.
>
> Any lines that end with a comment character (%) will skip over the newline
> character. Therefore, we can have newlines in the source code that wouldn't
> trigger the active newline character.
>
> The following example plain TeX document produces the text *foo bar baz*:
>
> *\catcode`\^^M=13*
>
>
> *\def^^M{ bar }%foobaz%*
> *\bye*
>
> Dne čtvrtek 27. října 2022 v 19:09:30 UTC+2 uživatel fiddlosopher napsal:
>
>>
>> > On Oct 27, 2022, at 12:07 AM, Bastien DUMONT <bastien...-VwIFZPTo/vqsTnJN9+BGXg@public.gmane.org>
>> wrote:
>> >
>> > Fortunately, it is possible by making the space and the newline
>> characters active in TeX! (Provided that a SoftBreak is rendered as a line
>> break in the TeX output.) This is how \obeylines and \obeyspaces work.
>>
>> But this might not be what you want; after all there are going to be
>> spaces in code blocks, and you might not want to treat them the same way
>> (they do not correspond to pandoc Space elements). There may also be line
>> breaks in the source that don't correspond to SoftBreak.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/9dfc8b26-3fda-4882-93b7-06d44671ef7fn%40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/9dfc8b26-3fda-4882-93b7-06d44671ef7fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAEe_xxiYD8Y5KJVB7WiKOo5xHbFWPq010rMXJEYsu_XNd-hX4A%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4761 bytes --]

Re: Plain TeX writer

[Vít Novotný]

[-- Attachment #1.1: Type: text/plain, Size: 4342 bytes --]

>  Would it be feasible for the https://ctan.org/pkg/markdown package to 
support an option to control whether to generate ASCII space or 
\pandocSpace (perhaps with a default of generation ASCII spaces)?

The https://ctan.org/pkg/markdown package is just a rendering backend for 
the various *\pandoc** macros. The decision to produce an ASCII space 
instead of the *\pandocSpace* macro falls on the plain TeX writer 
*pandoc-to-markdown.lua* from https://github.com/drehak/pandoc-to-markdown/. 
The option could be passed to the writer easily enough through metadata.

Dne středa 2. listopadu 2022 v 15:23:55 UTC+1 uživatel 
wlu...-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org napsal:

> Would it be feasible for the https://ctan.org/pkg/markdown package to 
> support an option to control whether to generate ASCII space or 
> \pandocSpace (perhaps with a default of generation ASCII spaces)?
>
> On Wed, 2 Nov 2022 at 14:17, Vít Novotný <wit...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> >  So, for example, you couldn’t make Spaces appear as visible ␠ 
>> characters, and you couldn’t make SoftBreaks create hard breaks in the 
>> output.
>>
>> Replacing *\pandocSpace* with ASCII spaces makes it difficult to 
>> reprogram spaces on the top level of the document, but we can definitely 
>> substitute spaces in parameters of commands such as  *\pandocCode*, 
>> which would cover many (if not most) use cases.
>>
>> The following example LaTeX document produces the text 
>> *we␣want␣visible␣spaces␣here* in a monospaced font:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *\documentclass{standalone}\usepackage{xparse}\ExplSyntaxOn\ProvideDocumentCommand  
>> { \pandocCode }  { m }  { \pandoc_code:n { #1 } }\cs_new:Nn  
>> \pandoc_code:n  {    \tl_set:Nn \l_tmpa_tl { #1 }    
>> \regex_replace_all:nnN      { \s }      { \c{textvisiblespace} }      
>> \l_tmpa_tl    \texttt { \l_tmpa_tl }  
>> }\ExplSyntaxOff\begin{document}\pandocCode{we want visible spaces 
>> here}\end{document}*
>>
>> >  There may also be line breaks in the source that don't correspond to 
>> SoftBreak.
>>
>> Any lines that end with a comment character (%) will skip over the 
>> newline character. Therefore, we can have newlines in the source code that 
>> wouldn't trigger the active newline character.
>>
>> The following example plain TeX document produces the text *foo bar baz*:
>>
>> *\catcode`\^^M=13*
>>
>>
>> *\def^^M{ bar }%foobaz%*
>> *\bye*
>>
>> Dne čtvrtek 27. října 2022 v 19:09:30 UTC+2 uživatel fiddlosopher napsal:
>>
>>>
>>> > On Oct 27, 2022, at 12:07 AM, Bastien DUMONT <bastien...-VwIFZPTo/vqsTnJN9+BGXg@public.gmane.org> 
>>> wrote: 
>>> > 
>>> > Fortunately, it is possible by making the space and the newline 
>>> characters active in TeX! (Provided that a SoftBreak is rendered as a line 
>>> break in the TeX output.) This is how \obeylines and \obeyspaces work. 
>>>
>>> But this might not be what you want; after all there are going to be 
>>> spaces in code blocks, and you might not want to treat them the same way 
>>> (they do not correspond to pandoc Space elements). There may also be line 
>>> breaks in the source that don't correspond to SoftBreak. 
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "pandoc-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pandoc-discuss/9dfc8b26-3fda-4882-93b7-06d44671ef7fn%40googlegroups.com 
>> <https://groups.google.com/d/msgid/pandoc-discuss/9dfc8b26-3fda-4882-93b7-06d44671ef7fn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/d2933f0d-4a51-4fd4-bb4f-32b5da362ab9n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6633 bytes --]