xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clay Leeds <the.webmaes...@gmail.com>
Subject Re: FOP Release Automation
Date Thu, 24 Jul 2014 17:00:10 GMT
On Jul 24, 2014, at 9:45 AM, Vincent Hennebert <vhennebert@gmail.com> wrote:
> [Moving to general@ as other sub-projects can benefit from this too.]
> I thought I would have a go at it and believe I’ve found a solution.
> There was a problem of conflicting syntaxes between Markdown’s way of
> specifying custom header IDs, and Dotiac::DTL’s syntax for comments.

Sounds like a good solution.

> For example:
>    ## Project Status {#status}
> The ‘{#status}’ is Mardown’s way of giving a custom ID to the generated
> H2 element. But ‘{#’ is also a way to introduce a comment in
> a Dotiac::DTL template, which then complains that there is no closing
> ‘#}’.
> Fortunately, both can be made to agree by inserting a space between ‘{’
> and ‘#’:
>    ## Project Status { #status}
> The Dotiac:DTL comment has now gone, but Markdown still recognises it as
> a custom ID. (A lot of them are actually unnecessary since they are
> identical to the title, and would be automatically generated by the
> Markdown HeaderId extension. They come from the conversion of Forrest
> sources, at some point we may want to scan through and remove them.)

Yeah. I implemented that change, so we could have TOC-style links. At the time I didn't believe
the Titles would be auto-generated.

> As you may have noticed I’ve just committed a batch change of header IDs
> that introduces that space. Now we can enable pre-processing of the
> Markdown sources and enjoy the use of variables (and much more if you are
> daring).
> Fortunately there’s hardly any Perl involved. We just need to set some
> parameters in the path.pm and define variables there. See
> http://svn.apache.org/r1613178 for more details. I’ve added just two
> variables as a proof of concept but now we can proceed scanning the
> sources and adding more variables.
> I don’t know whether there’s a risk that our variables conflict with the
> CMS’ own variables. If we name them properly (e.g., prefixing them with
> fop_ or batik_ or xgc_), then this should not happen.
> Vincent

+1 from me.

Nice that we can implement this by defining those vars in lib/path.pm and the perl fix is
so simple.

To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message