bpj / pandoc-attr-color Goto Github PK

Hi. it seems that I have a bug when I am highlighting a text that is longer than a standard line.

The code below:

We dealt with the multiple sensor frequencies and their asynchronicity by re-sampling, for each flight, all the input and output time-series on a common 10Hz time vector **[following a backward filling method blablalblalblabla]{bg=yellow}[(Commentaire Loic: À vérifier)]{fg=red}**.

Results in this:

I am forgetting something? I am using the last version of the filter.

Add configuration for box height/border padding/border width.

Currently the LaTeX code generator always adds a \strut after the span contents so as to make sure that the boxes around it aren't too tight, but this is very heavyhanded, and will cause a box directly below a box to overlap the upper box hiding its frame, and it is also a matter of taste.

A more flexible solution would be \parbox[c][<length>][c]{0pt}{}, where <length> is a valid length taken either from a default in the metadata of from an ht attribute, defaulting to 0.8em, even though the code is ugly as hell!

Likewise the CSS box padding (currently hard coded at 0.1em) and CSS box border width (currently hard coded at 0.01em) should be configurable either through metadata defaults or attributes, though I'm not sure what to call those attributes, possibly bp for boxpadding (or simply pad) and lw for linewidth. Perhaps also ls linestyle. There may be a problem in that different methods and hence parameters are required to increase the box padding in LaTeX and HTML, and line width and style are not configurable in LaTeX. (Unless I go through the hassle of loading and using Tikz and getting that to look good. At one point I used Tikz to simulate different styles of underlining as found in an old printed article. It wasn't easy!)

In order to possibly make the interface less verbose all these dimensions could be specified as percentages of an em so that the user types ht=80 to set the box height to 0.8em, bp=20 to set the box padding to 0.2em and lw=2 to set the line width to 0.02em. This could be combined with setting an explicit unit with code like this:

if length:match('^%d+$') then
  assertf(
    (length:len() <= 3),
    'Expected %s to be a percentage (1 to 3 digits) of an em', name
  )
  length = ('%sem'):format(length / 100)

Make a note in the README.md that the inline table showing the rendered HTML is currently broken because GitHub scrubs the spans. Probably an image showing the rendered HTML should be added, even though it will be nearly identical to the rendered LaTeX!

When formatting/concatenating the latex "post" markup we currently rely on the items in the post array to be just strings of closing curly brackets so that it doesn't matter in which order they are concatenated. To be safe against future additions to the post templates and against people copying the "algorithm" we should add a reverse_array helper function and call it on the post array before concatenating it.

local function reverse_array (arr)
  if 'table' == type(arr) then
    local rev = {}
    for i=#arr, 1, -1 do
      rev[#rev+1] = arr[i]
    end
    return rev
  end
  error"Expected argument to be table"
end

  post = table.concat( reverse_array(post) )

Document that the filter doesn't "know" any CSS/xcolor predefined color names!

Rather the filter trusts the user to know and use valid color names. This is kind of intentional since users may define custom color names in their LaTeX (preamble) source. It is also kind of necessary since otherwise the filter would have to include a huge table of all the CSS color names and check color names against it in HTML mode. However it is important to be aware because LaTeX (xcolor) will choke on invalid color names while CSS will just ignore them.

The \fcolorbox command of xcolor has a nasty "feature":

If only the first optional argument is given, it specifies the color model for both colors.

which means that the LaTeX markup as currently produced by this filter causes a "missing number" error! The "named" model has to be included explicitly:

% These are equivalent:
\fcolorbox[HTML]{framecolor}{boxcolor}{text}
\fcolorbox[HTML]{framecolor}[HTML]{boxcolor}{text}

% FIXME so this (as currently generated BREAKS:
\fcolorbox[HTML]{FF0000}{yellow}{text}

% and has to be replaced by this, which WORKS
\fcolorbox[HTML]{FF0000}[named]{yellow}{text}

Although this is a bit of overkill I will change the filter to always include [named] before a named color both to keep the filter code simple and to be safe.

Document issue #6