Okay, Sherwood, I think I'm getting it. You've got your site source in Markdown format. You want to change the images to HTML picture elements, each referring to three files that have a standardized naming scheme.
So you're working on how to do the text manipulations with Perl. And you wondered if anyone here has a better way to come at it or had already got a tool for the job. I thought you wanted to represent in Markdown syntax _which_ images to manipulate and/or their _dimension data_. And then run a script to make the change. Sorry I can't help with Perl. Stack Overflow or a Perl discussion site is sure to have folk who can. I hadn't heard of Template Toolkit; thanks for that. For running my sites I use [Void] as a backbone and build it out with tweaks and expansions to the PHP and CSS as needed. [Void]: https://github.com/josephernest/void Cheers, Thomas > On 30 Mar 2019, at 10:56 AM, Sherwood Botsford <sgbotsf...@gmail.com> wrote: > > My parser doesn't support that extra syntax, and I don't understand perl well > enough to swap parsers in Template Toolkit. > > I'm not sure how it helps me. While I can add attributes this way, I still > need to rewrite image.jpg as a series of strings, image-S.jpg; image-M.jpg; > and image-L.jpg > > Another key aspect of this: My website at present has 300 pages in it. A sed > script to turn <DIV class=picture> to <div class=picture> is a lot easier > than editing every image reference. > > > Regards > > Sherwood > > > > On Fri, 29 Mar 2019 at 20:41, Tom Humiston <t...@jumpingrock.net> wrote: > Maybe I misunderstand you but I think one or the other of these will work: > > > {.parse_me} > >  > > > The latter example is standard Markdown, the former adds a class in the > manner of PHP Markdown Extra (and other parsers as well, I think). > > If you post-process, what you'll parse isn't much different from that: > > > <img src="/path/to/image.jpg" alt="Alt text here" class="parse_me" /> > > <img src="/path/to/image.jpg" alt="Alt text here" title="700 500 50 10 > 138, 1400 1000 100 50 416" /> > > > Whether you parse Markdown or HTML, all your script needs to look for is a > class (or title) such as 'parse_me' OR a title consisting of numbers. > Assuming that the filenames to be generated all follow the same pattern. > > > So all I need to do is write a code snippet that turns > > > >  into the corresponding set of picture > > and src image tags. > > > Yup, I think we're just talking about two different ways of marking the > images that your snippet will parse. > > HTH, > T > > > > > On 29 Mar 2019, at 7:44 AM, Sherwood Botsford <sgbotsf...@gmail.com> wrote: > > > > > > Reason I'm more inclined to preprocess is as follows: > > > > Markdown is visually simpler to parse. > > > > In template toolkit, I create the navigation system, using a 200 line TT2 > > script. It's messy. TT2 calls a markdown plugin. > > > > By using the <DIV> versus <div> I have a clear flag to identify where I > > need to work. I think this will be simpler to do without going off the > > rails. > > > > So all I need to do is write a code snippet that turns > > > >  into the corresponding set of picture > > and src image tags. > > > > If I use a variable for the parameters to pass to the srcset criteria, then > > I can change this once for the entire site. > > > > It will mean creating at least 2 additional images for each currently used > > image. > > > > > > > > Regards > > > > Sherwood > > > > > > > > On Wed, 27 Mar 2019 at 17:07, Tom Humiston <t...@jumpingrock.net> wrote: > > Sherwood, great question and well laid out. If a good solution comes up > > I'll probably want it as well. > > > > My idea is to _post-process_ the HTML output to convert marked data into a > > picture element, rather than to construct a picture up front that can > > withstand parsing from Markdown into HTML. In the source text, I suggest > > cramming the image's source data into the image's title attribute, which > > then gets unpacked in the post-processing. > > > > I wrote the following as I was working out the idea. > > > > --- > > > > I haven't become familiar with the `<picture>` element but I get the idea > > from what you've presented. As for the CSS presentation, fancier things are > > of course possible but that doesn't change the need for well-structured > > content and good markup. > > > > Like you, I've got no Javascript background, and I'm happy enough to keep > > it that way. In fact I'm not much of a programmer at all, which may be an > > advantage as I try to always empathize with the non-technical writers and > > readers. > > > > So I'm looking at the data salad that supports 'picture' and thinking it > > hardly fits into standard prose, and I think one way to come at it is, > > firstly, to pick the appropriate existing Markdown that will tuck the > > structured data into a place it would pose no harm if visible to readers, > > and, secondly, to write a script that will _post-process_ the HTML and > > rewrite the element containing the picture data as a picture element at the > > desired position. > > > > That is: > > > > 1. Process your Markdown into HTML. > > 2. Post-process the HTML to rewrite instances of picture data as > > `<picture>` elements. > > > > For the first step, two options that come to mind use extended Markdown > > syntax: the footnote and the description list. > > > > In either case I suppose you could include a keyword or key bit of syntax > > to mark the data in a way that will cause your bespoke post-processing > > script to recognize and act upon it. > > > > A __footnote__ would place the structured data _outside the flow of the > > main text_ (suitable if there is no post-processing) and allow almost any > > variety of temporary syntax for arranging that data. Another advantage is > > that the HTML link to the footnote, which would indicate where your script > > should insert the picture, can reside within a block-level element just as > > an `img` now can. (The downside is that the footnote link cannot exist > > _without_ associated block-level content. Oh well.) Note that the keyword > > cannot be the footnote marker itself, as this is processed out by the > > Markdown script (at least in the implementations of which I'm aware). > > > > A __description list__ would place the data in a DL element, structured > > either as a series of DT-DD pairs, or as the content of a single pair which > > you could again structure in any fashion (as with the footnote). A > > disadvantage is that the data will fall more within the surrounding prose > > than would a footnote, but advantages may exist as well. > > > > Below are examples of the Markdown I imagine, each using `\picture-data\` > > as the identifier to be recognized in post-processing. To structure the > > data I merely remove the angle brackets and line breaks (to minimize > > Markdown processing) and add semicolons as delimiters. The last example > > builds on the standard Markdown image format and thus does not require > > extended syntax. > > > > > > ## Example 1: Footnote > > > > A picture[^pic1] will go inside this paragraph. > > > > [^pic1]: \picture-data\ source media="(max-width: 700px)" > > sizes="(max-width: 500px) 50vw, 10vw" srcset="stick-figure-narrow.png 138w, > > stick-figure-hd-narrow.png 138w"; source media="(max-width: 1400px)" > > sizes="(max-width: 1000px) 100vw, 50vw" srcset="stick-figure.png 416w, > > stick-figure-hd.png 416w"; img src="stick-original.png" alt="Human" > > > > > > ## Example 2: Description List with Single Term > > > > Lorem ipsum dolor sit amet consectetur adipiscing whatever. > > > > \\picture-data\\ > > : source media="(max-width: 700px)" sizes="(max-width: 500px) 50vw, > > 10vw" srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png > > 138w"; source media="(max-width: 1400px)" sizes="(max-width: 1000px) 100vw, > > 50vw" srcset="stick-figure.png 416w, stick-figure-hd.png 416w"; img > > src="stick-original.png" alt="Human" > > > > Lorem ipsum dolor sit amet consectetur adipiscing more of whatever. > > > > > > ## Example 3: Description List with Multiple Terms > > > > \\picture-data\\ > > > > source1 > > : media="(max-width: 700px)" sizes="(max-width: 500px) 50vw, 10vw" > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png 138w" > > > > source2 > > : media="(max-width: 1400px)" sizes="(max-width: 1000px) 100vw, 50vw" > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"; > > > > img > > : src="stick-original.png" alt="Human" > > > > > > ## Example 4: Image + Footnote > > > > Presumably you'd like a basic one-size-fits-all-screens 'img' element to be > > displayed in case there is no post-processing to create a picture element. > > Shifting the additional source data (beyond what is required for img) into > > a footnote could still be a good answer: > > > > [^pic4] > > > > [^pic4]: \picture-data\ source media="(max-width: 700px)" > > sizes="(max-width: 500px) 50vw, 10vw" srcset="stick-figure-narrow.png 138w, > > stick-figure-hd-narrow.png 138w"; source media="(max-width: 1400px)" > > sizes="(max-width: 1000px) 100vw, 50vw" srcset="stick-figure.png 416w, > > stick-figure-hd.png 416w" > > > > > > ## Example 5: Image with Title > > > > This variation has the advantage that the additional source info is not > > visible (in ordinary contexts, although it's still part of the HTML > > content): > > > > ![Human][human] > > > > [human]: stick-original.png '\picture-data\ source media="(max-width: > > 700px)" sizes="(max-width: 500px) 50vw, 10vw" > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png 138w"; > > source media="(max-width: 1400px)" sizes="(max-width: 1000px) 100vw, 50vw" > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"' > > > > The reference form can be used (i.e. image info moved further down the > > page), as shown above. Either way, however, a distinct disadvantage of the > > img approach is that quotes may need to be escaped, since the value of the > > title attribute must be quoted and the value itself (at least as I've been > > showing it) contains quotes. > > > > --- > > > > In each example above, I assumed that your post-processing script will look > > for `\picture-data\` and rewrite the related HTML using the string of data > > that follows. > > > > In the case of a footnote, the script would need to find the related link > > and insert the picture element there. If HTML5 does not define `<picture>` > > as a block element and you wish it this one to be so, I suppose you'd need > > to add 'block' or something to your picture-data so that it can influence > > the post-processing. CSS classes and IDs can be added as well in this > > fashion. > > > > Example 5, the image-with-title, is possibly the best of these suggestions > > — unless your preferred Markdown implementation chokes on nested quotes in > > image titles. (The dingus at Daring Fireball renders the double-quotes in > > the example as `"` entities. The parser inside the 1Writer app does > > this in all the examples. Okay, so your post-processor converts these back > > to quotes.) > > > > Some last thoughts: > > > > - This sort of post-processing approach frees you from having to write any > > HTML for your picture, let alone HTML with case-sensitive tags. > > - Other Markdown options that occurred to me later include a table and > > nested lists, but I see little advantage (beyond some semantic correctness > > if they aren't processed out) and so didn't include them above. > > - PHP Markdown Extra allows class and ID to be set on images. (And on code > > blocks. The image-source data, for typical reading purposes, is > > programmatic, i.e. it's code, so that would be semantically appropriate > > markup.) Classes and IDs can aid what we're trying to do here. > > - I already use post-processing in my PHP to rewrite footnote links (so > > that they don't conflict with those of other blog posts on the same page) > > and find the lag unnoticeable. > > > > > > Hoping this helps, > > Thomas Humiston > > > > > > > > > On 27 Mar 2019, at 10:22 AM, Sherwood Botsford <sgbotsf...@gmail.com> > > > wrote: > > > > > > > > > I like markdown. I use it in combination with Template Toolkit, and > > > basically I don't have to write any html. My webpages are static, having > > > only the js snippet that Google analytics uses. I would mostly like to > > > keep it that way. I have zero javascript experience. > > > > > > I can do some degree of simple page layout using a handful of classes > > > applied to DIVs. > > > > > > So this > > > > > > <DIV class=picr3> > > > > > > ![Shelterbelt-12][2] > > > > > > Planting a shelterbelt, or any tree project... > > > > > > *** > > > > > > </DIV> > > > [2]: /Images/Shelterbelt/Shelterbelt-12.jpg > > > > > > is all the html I need to use to have an image sized to width 30% of the > > > Content div floated to the right. The system isn't perfect, but it > > > resizes reasonably well, and since the page is static it caches well, and > > > is fast to deliver. > > > > > > More important to me: I can spend time writing content, and very little > > > tweaking layout. > > > > > > The problem: If I serve an nice desktop image to a mobile phone, > > > download times are high. If I serve an image of reduced resolution to > > > make phone access quick, it looks like crap on a desktop. > > > > > > > > > > > > In Html we now have the <picture> element, combined with the srcset and > > > size attributes. This turns what used to be a simple img tag into this: > > > > > > <picture> > > > <source media="(max-width: 700px)" sizes="(max-width: 500px) 50vw, > > > 10vw" > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png > > > 138w"> > > > > > > <source media="(max-width: 1400px)" sizes="(max-width: 1000px) 100vw, > > > 50vw" > > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"> > > > > > > <img src="stick-original.png" alt="Human"> > > > </picture> > > > > > > At this point, I'm looking at having to roll my own solution much along > > > this line: > > > > > > * Replace <DIV> with <div> On my implementation of Markdown, being > > > between lower case tags means that the content of that tag is not > > > Markdown processed. > > > > > > * Come up with a standard naming convention, say whateverimage-L.jpg for > > > the large version, -M.jpg for the medium version and -S. jpg for the > > > small version. > > > > > > * Pre process the resulting markdown files to generate the full <picture> > > > element from the embedded markdown. I think this is within my limited > > > perl programming capabilities. > > > > > > Gotchas? > > > > > > This wheel has been invented already? > > > > > > Better ways to approach this? Should I bite the bullet and do this with > > > a javascript snippet? > > > > > > Some other solution I've missing in my wandering of 'a maze of twisty > > > passages, all different' that is the internet? > > > > > > > > > Regards > > > > > > Sherwood > > > > > > _______________________________________________ > > > Markdown-Discuss mailing list > > > Markdown-Discuss@six.pairlist.net > > > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss > > > > _______________________________________________ > > Markdown-Discuss mailing list > > Markdown-Discuss@six.pairlist.net > > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss > > _______________________________________________ > > Markdown-Discuss mailing list > > Markdown-Discuss@six.pairlist.net > > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss > > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss@six.pairlist.net > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss@six.pairlist.net > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss _______________________________________________ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
