SendGrid Dynamic Templates always produces non-ASCII symbol instead of HTML escaping, causing Message Clipped - sendgrid

Question: Has anyone had any luck forcing Sendgrid Dynamic Templates to use © with a text module inside a single-column layout? It always produces the non-ASCII © for me.
Detail
Gmail penalises any content that contains non-ASCII characters. When it detects this it shows the "Message clipped" message at the bottom. This is not an ideal professional look.
The source of this for us was the © copyright symbol. This is because Sendgrid Dynamic Templates always passes this directly with non-ascii version instead of using html-escaped ©
I tried to get around this by editing the html and forcing © but the editor simply replaced it with the bad © char each time.
Steps to reproduce:
Create a single column layout with a text module inside. Add “Test copyright ©”
Edit module HTML for text component. It will initially have the © Symbol in there
Change to be html-escaped © and click Update
Repeat step (2) to view the source and the source code will contain the unescaped copyright © symbol. This will continue to cause "Message clipped"

I've raised a request with SendGrid as I think this is a bug, but a note for others meanwhile is that you can work around this by:
Creating a Code component inside your single-column layout,
Copy any styling you want from the original Text element by viewing the source
You may also need to copy any padding, line-height from the table of the original text element by viewing the source of the generated template
This got me my outcome, but obviously isn't as easy to allow non-tech authors to maintain the content.
Update 9 Feb 2023
SendGrid support have confirmed the bug with all rich text editors. Copyright symbol is always replaced with unicode character instead of html escape code. Should ideally always convert known special characters to html escape codes, but at a minimum it should honour when someone overrides in the code section rather than replacing it. Bug raised, no ETA or idea of internal prioritisation. Meanwhile workaround above will get you by ... just makes it harder for non-technical authoring.

Related

Markdown metadata format

Is there a standard or convention for embedding metadata in a Markdown formatted post, such as the publication date or post author for conditional rendering by the renderer?
Looks like this Yaml metadata format might be it.
There are all kinds of strategies, e.g. an accompanying file mypost.meta.edn, but I'm hoping to keep it all in one file.
There are two common formats that look very similar but are actually different in some very specific ways. And a third which is very different.
YAML Front Matter
The Jekyll static site generator popularized YAML front matter which is deliminated by YAML section markers. Yes, the dashes are actually part of the YAML syntax. And the metadata is defined using any valid YAML syntax. Here is an example from the Jekyll docs:
---
layout: post
title: Blogging Like a Hacker
---
Note that YAML front matter is not parsed by the Markdown parser, but is removed prior to parsing by Jekyll (or whatever tool you're using) and could actually be used to request a different parser than the default Markdown parser for that page (I don't recall if Jekyll does that, but I have seen some tools which do).
MultiMarkdown Metadata
The older and simpler MultiMarkdown Metadata is actually incorporated into a few Markdown parsers. While it has more recently been updated to optionally support YAML deliminators, traditionally, the metadata ends and the Markdown document begins upon the first blank line (if the first line was blank, then no metadata). And while the syntax looks very similar to YAML, only key-value pairs are supported with no implied types. Here is an example from the MultiMarkdown docs:
Title: A Sample MultiMarkdown Document
Author: Fletcher T. Penney
Date: February 9, 2011
Comment: This is a comment intended to demonstrate
metadata that spans multiple lines, yet
is treated as a single value.
CSS: http://example.com/standard.css
The MultiMarkdown parser includes a bunch of additional options which are unique to that parser, but the key-value metadata is used across multiple parsers. Unfortunately, I have never seen any two which behaved exactly the same. Without the Markdown rules defining such a format everyone has done their own slightly different interpretation resulting in a lot of variety.
The one thing that is more common is the support for YAML deliminators and basic key-value definitions.
Pandoc Title Block
For completeness there is also the Pandoc Title Block. If has a very different syntax and is not easily confused with the other two. To my knowledge, it is only supported by Pandoc (if enabled), and it only supports three types of data: title, author, and date. Here is an example from the Pandoc documentation:
% title
% author(s) (separated by semicolons)
% date
Note that Pandoc Title Blocks are one of two style supported by Pandoc. Pandoc also supports YAML Metadata as described above.
A workaround use standard syntax and compatible with all other viewers.
I was also looking for a way to add application specific metadata to markdown files while make sure the existing viewers such as vscode and github page will ignore added metadata. Also to use extended markdown syntax is not a good idea because I want to make sure my files can be rendered correctly on different viewers.
So here is my solution: at beginning of markdown file, use following syntax to add metadata:
[_metadata_:author]:- "daveying"
[_metadata_:tags]:- "markdown metadata"
This is the standard syntax for link references, and they will not be rendered while your application can extract these data out.
The - after : is just a placeholder for url, I don't use url as value because you cannot have space in urls, but I have scenarios require array values.
Most Markdown renderers seem to support this YAML format for metadata at the top of the file:
---
layout: post
published-on: 1 January 2000
title: Blogging Like a Boss
---
Content goes here.
The most consistent form of metadata that I've found for Markdown is actually HTML meta tags, since most Markdown interpreters recognize HTML tags and will not render meta tags, meaning that metadata can be stored in a way that will not show up in rendered HTML.
<title>Hello World</title>
<meta name="description" content="The quick brown fox jumped over the lazy dog.">
<meta name="author" content="John Smith">
## Heading
Markdown content begins here
You can try this in something like GitHub Gist or StackEdit.
Correct.
Use the yaml front matter key-value syntax — like MultiMarkdown supports — but (ab)use the official markdown URL syntax to add your metadata.
… my workaround looks like this:
---
[//]: # (Title: My Awesome Title)
[//]: # (Author: Alan Smithee)
[//]: # (Date: 2018-04-27)
[//]: # (Comment: This is my awesome comment. Oh yah.)
[//]: # (Tags: #foo, #bar)
[//]: # (CSS: https://path-to-css)
---
Put this block at the top of your .md doc, with no blank line between the top of the doc and the first ---.
Your fake yaml won't be included when you render to HTML, etc. … it only appears in the .md.
You can also use this technique for adding comments in the body of a markdown doc.
This is not a standard way, but works with Markdown Extra.
I wanted something that worked in the parser, but also didn't leave any clutter when I browse the files on Bitbucket where I store the files.
So I use Abbreviations from the Markdown Extra syntax.
*[blog-date]: 2018-04-27
*[blog-tags]: foo,bar
then I parse them with regexp:
^\*\[blog-date\]:\s*(.+)\s*$
As long as I don't write the exact keywords in the text, they leave no trace. So use some prefix obscure enough to hide them.
I haven't seen this mentioned elsewhere here or in various blogs discussing the subject, but in a project for my personal website, I've decided to use a simple JSON object at the top of each markdown file to store metadata. It's a little more cumbersome to type compared to some of the more textual formats above, but it's super easy to parse. Basically I just do a regex such as ^\s*({.*?})\s*(.*)$ (with the s option on to treat . as \n) to capture the json and markdown content, then parse the json with the language's standard method. It allows pretty easily for arbitrary meta fields.

strikethrough code in markdown on github

I am talking about github markdown here, for files like README.md.
Question:
Is it possible to strikethrough a complete code block in markdown on github?
I know how to mark text as a block of code
this is
multiline code
and
this
this
also
by indenting by 4 spaces or by using ``` or `...
I also know how to strike through texts using
del tag
s tag
~~
Temporary solution:
Independently they work fine, but together not as expected or desired. I tried several combinations of the above mentioned.
For now, I use this:
striked
through
by using ~~ and ` for every single line.
Requirement:
I would like to have a code formatted text striked through, where the code block is continuous:
unfortunately, this is
not striked through
or at least with only a small paragraph in between:
unfortunately, also not
striked through
Is this possible at all?
I found some old posts and hints on using jekyll, but what I was searching for is a simple way, preferably in markdown.
This would only be possible with raw HTML, which GitHub doesn't allow. But you may be able to use a diff instead.
Code blocks are for "pre-formatted" text only. The only formatting you can get in a code block is the formatting that can be represented in plain text (indentation, capitalization, etc). There is no mechanism to mark up the content of a code block (as bold, italic, stricken, underlined, etc). This was an intentional design decision. Otherwise, how would you be able to show Markdown text in a code block? If you want formatted text, then you need to use something other than a code block.
As the rules state:
HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.
For any markup that is not covered by Markdown’s syntax, you simply use HTML itself.
Therefore you would need to format your own custom HTML code block with the various bits marked up properly:
<pre><code><del>some stricken code</del>
<del>A second line of stricken code</del>
</code></pre>
However, for security reasons, GitHub will strip out any such raw HTML in your Markdown. So while this works where you have full control of the entire stack, on a hosted service it is most likely not possible.
However, I'm assuming you want to show some changes made to a block of code. As it turns out, a specific format already exists for that, namely, a diff. Just use a fenced code block with diff as the language and GitHub will format it correctly:
```diff
Unchanged Line
- Removed Line
+ Added Line
```
You can see how GitHub displays the above code block live (you can also see that in raw), but I've included a screenshot below for convenience.
I realize that the formatting does not use strike-through, but it does use a commonly used and understood format. For more complex blocks, you should probably use the diff utility program to generate the diff for you.
Expanding on Waylan's answer:
This may be obvious to others, but it caught me. When you have indented lines, be sure + or - is the first character on the line or it won't highlight.
```diff
<div>
Unchanged Line
<ul>
- <li>This won't work</li>
- <li>This will</li>
+ <li>1st character, then indent</li>
</ul>
</div>
```
After much much trying, I finally got it to work! It boils down to this:
inside ``` block, nothing is rendered (other than syntax highlights for language specified)
inside <code> block, markdown won't render, only HTML. You can use <strike>. It's fine, but you don't get the syntax coloring
now for the magic: use HTML for striking, and markdown for coloring:
<strike>
```language
this is
multiline code
```
</strike>
P.S. ``` blocks should always be surrounded by blank lines to work
On the subject of marking up the content of a code block, to tack an italicized string on to the end of a line of "code", try something like:
<code>id\_pn\_aside\_subscriber\_form\__form\_id_</code>
(You can see this in action at: https://github.com/devonostendorf/post-notif#how-do-you-use-the-stylesheet_filename-attribute-with-the-shortcode)
I had a hard time finding an example that matched this precise use case, so I hope this proves useful for anyone else trying to accomplish a similar effect.

Copy formatted text to clipboard

A simple html page has FORMATTED text - not fancy - line breaks, and italic.
I want to have a button that takes this formatted text, and copies it to the clipboard, formatted (it is planned to be pasted into some LibreOffice document later).
Couldn't find how to do it.
I tried ZeroClipboard, and a suggestion to parse the text, replacing ""-s to "\r\n". That indeed does the trick for line breaks, but what about italic?... Any means to get this functionality?...
When you create an italic tag the responsible for formatting the document and showing the text properly is the browser. If you want to copy the text you should get the text already parse and render by the browser or parse yourself the text like you did with break lines. For italics when you find a ... tag you must create the adequate text. That is, text in italics, but that depends on the language you are using, but i'm sure it can be done.
OK,
Turns out that ZeroClipboard had this functionality (of rendering the HTML text upon paste), but have disabled it.
However, the version that supports it can be found at: https://github.com/botcheddevil/ZeroClipboard
Note:
You may find that in this version, creating the client, binding the flash to a component, and handling the events are rather different than the documentation of current version of ZeroClipboard (https://github.com/zeroclipboard/zeroclipboard/blob/master/docs/instructions.md

How can I stop TinyMCE from converting HTML entities back to special characters?

When I put something like £ or © into my TinyMCE editor and save the text, then when I load the text back from the database, it appears to turn into the actual £ and © characters. I don't want that. When I check my database, I see that these symbols are stored as £ and ©, so it's not a storage problem. Also if I try to store the symbols as &pound; and &copy;, that doesn't work either, as the character sequences are still converted into original symbols.
What can I do to fix this?
Thanks.
You may insert a zero-width-no-break-space between & and pound. This way the editor won't recognise it as an entity/character.
It turns out that I can just htmlspecialchars() the text in my PHP script, and it correctly handles both the formatting and the sequences that are entered. This is rather unexpected, but it actually works out to do the right thing.

Japanese characters in a latex \section{} cause an error

I am working on getting Japanese documents created with latex. I have installed the latest version of texlive-2008 which includes CJK.
In my document I have the following:
\documentclass{class}
\usepackage{CJK}
\begin{document}
\begin{CJK*}{UTF8}{min}
\title{[Japanese Characters here 1]}
\maketitle
\section{[Japanese Characters here 2]}
[Japanese Characters here 3]
\end{CJK*}
\end{document}
In the above code there are 3 locations Japanese characters are used.
1 + 3 work fine whereas 2, which contains Japanese characters in a \section{} fails with the following error.
! Argument of \#sect has an extra }.
After some research it turns out this error manifests when you’ve put a fragile command inside a moving argument. A moving argument because section can be moved to a contents page for example.
Does anyone know how to get this to work and why latex thinks Japanese characters are "fragile".
Sorry to post this as an answer rather than a comment to your answer; I don't have enough rep yet to comment. (EDIT: Now I have enough rep to comment, but I'm not sorry anymore. Thanks Will.)
Your solution of replacing
\section{[Japanese Text]}
with
\section{\texorpdfstring{[Japanese Text]}{}}
suggests that you're using the hyperref package. When you use the hyperref package, any sort of not-totally-boring text (e.g. math) within \section causes a problem because \section is having trouble generating pdf bookmarks. \texorpdfstring allows you to specify how you want the section title to appear in the pdf bookmark. For example, I might write
\section{Calculation of \texorpdfstring{$H_2(\mathcal{X})$}{H\_2(X)}}
if I want the section title to be "Calculation of $H_2(\mathcal{X})$" but I want the pdf bookmark to be "Calculation of H_2(X)".
You should probably use xetex/xelatex, as it has been created to support unicode. The change is sometimes not easy for already existing documents, though. (xelatex should be included in texlive, it is just different executable to call -- this is how it is done in Debian).
I have managed to get this working now!
Using Latex and CJK as before.
\section{[Japanese Text]}
was replaced with
\section{\texorpdfstring{[Japanese Text]}{}}
Now the contents pages and section titles work and update fine.