public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: H <agents-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: Wrapping sections of text with <div></div> in custom filter
Date: Mon, 12 Jun 2023 17:18:31 -0400	[thread overview]
Message-ID: <EAF5063B-4655-48B3-8961-AF664AE3C94F@meddatainc.com> (raw)
In-Reply-To: <CAEe_xxjer3B9Qy8oGGNx_ARySSMD1mG8-AD6-EJQQXYnddFMYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On June 12, 2023 5:09:20 PM EDT, 'William Lupton' via pandoc-discuss <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> wrote:
>I'm not sure whether this helps in your situation, but if the image has
>no
>alt text then there'll be no caption in the HTML (and no figure element
>either). This document:
>
>![test](https://www.somedomain.tld/test.jpg)
>
>![](https://www.somedomain.tld/test.jpg)
>
>...gives this HTML:
>
><figure>
><img src="https://www.somedomain.tld/test.jpg" alt="test" />
><figcaption aria-hidden="true">test</figcaption>
></figure>
><p><img src="https://www.somedomain.tld/test.jpg" /></p>
>
>See https://pandoc.org/MANUAL.html#extension-implicit_figures
>
>
>On Sun, 11 Jun 2023 at 16:54, H <agents-FcZObrvlYduBUy7/sJONFg@public.gmane.org> wrote:
>
>> On 06/11/2023 09:51 AM, BPJ wrote:
>>
>> An image will be wrapped in a `<figure>` when it is the only thing in
>a
>> paragraph, so the workaround is to add a non-breaking space after the
>> image.
>>
>> This filter removes the Figure leaving the Image and an nbspace in a
>Para
>> unless the Image has a class `.fig`.
>>
>> It can be used both to globally insert the needed nbspace into
>Markdown or
>> used always to so to speak implement a better syntax where you
>clearly mark
>> a lone-image paragraph if you want a figure.
>>
>> https://gist.github.com/bpj/6664b0b0755e7ebe9007de4d1426d400
>>
>> Den sön 11 juni 2023 04:26H <agents-FcZObrvlYduBUy7/sJONFg@public.gmane.org> skrev:
>>
>>> On 06/06/2023 03:14 PM, H wrote:
>>>
>>> On 06/01/2023 04:34 AM, 'William Lupton' via pandoc-discuss wrote:
>>>
>>> Am I correct in thinking that when you say "filter" here, you really
>mean
>>> "writer"?
>>>
>>> In filters, you can use the 'traverse' field to force top-down
>traversal.
>>> See https://pandoc.org/lua-filters.html#traversal-order
>>>
>>> In writers, you can choose to call doc:walk(), which will honour
>>> 'traverse'. See
>>>
>https://pandoc.org/custom-writers.html#example-modified-markdown-writer
>>> (and example below)
>>>
>>> However, if you use pandoc.scaffolding.Writer (as I think you are?)
>then
>>> I suspect that you can't control the traversal order (but I'm not
>sure that
>>> it makes sense to do so, because, for example, surely you always
>want the
>>> contents of a <div> to have been traversed before you add '<div>'
>and
>>> '</div>'?).
>>>
>>> With the custom writer shown below, and with an input file that
>consists
>>> of the single line 'Text' (and using my logging module
>>> <https://github.com/pandoc-ext/logging>), you get this with the
>default
>>> 'typewise' traversal:
>>>
>>> (#) inline Str "Text"
>>> (#) inlines Inlines[1] {[1] Str "Text"}
>>> (#) block Para {content: Inlines[1] {[1] Str "Text"}}
>>> (#) blocks Blocks[1] {[1] Para {content: Inlines[1] {[1] Str
>"Text"}}}
>>> (#) meta Meta {}
>>> (#) doc Pandoc {
>>>   blocks: Blocks[1] {
>>>     [1] Para {
>>>       content: Inlines[1] {
>>>         [1] Str "Text"
>>>       }
>>>     }
>>>   }
>>>   meta: Meta {}
>>> }
>>>
>>> ...and this with 'topdown' traversal:
>>>
>>> (#) doc Pandoc {
>>>   blocks: Blocks[1] {
>>>     [1] Para {
>>>       content: Inlines[1] {
>>>         [1] Str "Text"
>>>       }
>>>     }
>>>   }
>>>   meta: Meta {}
>>> }
>>> (#) meta Meta {}
>>> (#) blocks Blocks[1] {[1] Para {content: Inlines[1] {[1] Str
>"Text"}}}
>>> (#) block Para {content: Inlines[1] {[1] Str "Text"}}
>>> (#) inlines Inlines[1] {[1] Str "Text"}
>>> (#) inline Str "Text"
>>>
>>> The writer:
>>>
>>> local logging = require 'logging'
>>>
>>> local function report(label, elem)
>>>     logging.temp(label, elem)
>>> end
>>>
>>> -- 'typewise' (default) or 'topdown'
>>> local traverse = 'topdown'
>>>
>>> function Writer (doc, opts)
>>>     local filter = {
>>>         traverse = traverse,
>>>         Inline = function(inline)
>>>             report('inline', inline)
>>>         end,
>>>         Inlines= function(inlines)
>>>             report('inlines', inlines)
>>>         end,
>>>         Block = function(block)
>>>             report('block', block)
>>>         end,
>>>         Blocks = function(blocks)
>>>             report('blocks', blocks)
>>>         end,
>>>         Meta = function(meta)
>>>             report('meta', meta)
>>>         end,
>>>         Pandoc = function(doc)
>>>             report('doc', doc)
>>>         end,
>>>     }
>>>     return pandoc.write(doc:walk(filter), 'html', opts)
>>> end
>>>
>>> Thank you for your thoughtful response. I realize I have used the
>term
>>> 'filter' and 'writer' cavalierly. I have a "slightly" complicated
>layout I
>>> want to output from the writer and my thought right now is that I
>should
>>> try to add the <div> and </div> in the right places in a filter and
>then
>>> let the writer just output the resulting html.
>>>
>>> I may have to traverse the AST several times in my filter to
>accomplish
>>> the result since multiple <div></div> need to be added at different
>levels
>>> to achieve the desired output.
>>>
>>> I just downloaded your logging filter to aid in the development and
>am
>>> also working on formalizing the rules for adding <div></div>.
>>>
>>>
>>> I spent some more time learning more about writing filters and have
>made
>>> some progress.
>>>
>>> I think the entire logic for adding <div></div> to achieve the
>desired
>>> layout might be doable in the filter and most of it seems to be
>working.
>>>
>>> One thing I found is that when an image is included using the
>following
>>> syntax
>>> ![test](https://www.somedomain.tld/test.jpg)
>>> pandoc wraps the <image> element in <figure></figure> which I think
>I
>>> don't want/need.
>>>
>>> How can I get rid of <figure> wrapped around <image> elements? At
>the
>>> very least I want got get rid of <figurecaption>some text I do not
>>> need</figurecaption> inside the <figure></figure> element?
>>>
>>> Got it, thank you and I will look at your code. If I am not adding
>the
>> non-breakable space after the image however, how do I get rid of the
>> <figurecaption> element which I do not need (or want cluttering up my
>code)?
>>
>> --
>> 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/b189960a-3e0d-19b8-91e2-c16dc88cd595%40meddatainc.com
>>
><https://groups.google.com/d/msgid/pandoc-discuss/b189960a-3e0d-19b8-91e2-c16dc88cd595%40meddatainc.com?utm_medium=email&utm_source=footer>
>> .
>>

It does have alt text and I do want to keep that. I do, however, want to get rid of the <figurecaption> text - is this doable?

-- 
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/EAF5063B-4655-48B3-8961-AF664AE3C94F%40meddatainc.com.


  parent reply	other threads:[~2023-06-12 21:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-24 20:51 H
     [not found] ` <2fc450a6-5a16-316c-02c8-8ef055bccd11-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-24 23:20   ` H
     [not found]     ` <93e5b610-66a2-6ac7-1d53-8a04a8314249-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-25 10:42       ` Felix SOEDJEDE
     [not found]         ` <853c402b-d9ee-4c9d-8bae-15b20faf7194n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2023-05-25 19:36           ` H
     [not found]             ` <1F66BB1E-B5C8-4062-8202-D82C5CE9A3D0-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-25 20:38               ` 'William Lupton' via pandoc-discuss
     [not found]                 ` <CAEe_xxgNr8O73TNGgV5y=gwiLAKB3WFuX5a49Vv_RJDtojVcSQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-05-26  0:31                   ` H
     [not found]                     ` <6d414734-e661-ae2d-68a1-4dfc9cb4f035-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-26  6:33                       ` 'William Lupton' via pandoc-discuss
     [not found]                         ` <CAEe_xxg9ExgK4WCNz6G=r=s4DSCs4CBPERcUV431yov2UmeO8w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-05-26 19:43                           ` H
     [not found]                             ` <cee5298a-37c9-6e17-6370-eecda5d9d6fb-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-26 21:01                               ` 'William Lupton' via pandoc-discuss
2023-05-29  0:50                               ` H
     [not found]                                 ` <4c58dad0-bd86-608e-2d68-74bd6f2f808b-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-29  4:31                                   ` H
     [not found]                                     ` <F41D20AD-EDDD-4AF4-A9AD-AAB8581086BF-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-30 18:30                                       ` H
     [not found]                                         ` <574fbf9f-c1b8-711a-f14a-3acd75cbf634-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-05-30 19:23                                           ` H
     [not found]                                             ` <05ba5663-1578-d555-8539-d6a2bdff6743-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-06-01  8:34                                               ` 'William Lupton' via pandoc-discuss
     [not found]                                                 ` <CAEe_xxhTjZJRuNZFtYMqh1eSNM9yobfgs_YTj2muxs1px0ygjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-06-06 19:14                                                   ` H
     [not found]                                                     ` <7878b22d-bf64-2d25-1136-d9f9cf5e135b-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-06-11  2:25                                                       ` H
     [not found]                                                         ` <992af9a4-285c-a20f-56de-347ea88f021f-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-06-11 13:51                                                           ` BPJ
     [not found]                                                             ` <CADAJKhDBqvOL469ZXigacDug2dMx=OiGWjteOM3fXqT-29BM5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-06-11 15:54                                                               ` H
     [not found]                                                                 ` <b189960a-3e0d-19b8-91e2-c16dc88cd595-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-06-12 21:09                                                                   ` 'William Lupton' via pandoc-discuss
     [not found]                                                                     ` <CAEe_xxjer3B9Qy8oGGNx_ARySSMD1mG8-AD6-EJQQXYnddFMYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-06-12 21:18                                                                       ` H [this message]
     [not found]                                                                         ` <EAF5063B-4655-48B3-8961-AF664AE3C94F-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
2023-06-13  8:28                                                                           ` 'William Lupton' via pandoc-discuss
     [not found]                                                                             ` <CAEe_xxjdOUK-tpNsw65u_v_gNr0nUkF5vfrQc0RQyLhJyjtHSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-06-13 17:28                                                                               ` H

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EAF5063B-4655-48B3-8961-AF664AE3C94F@meddatainc.com \
    --to=agents-fczobrvlydubuy7/sjonfg@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).