#2296: Export wiki pages to latex
--------------------------------+-------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: athomas
Type: enhancement | Status: assigned
Priority: normal | Milestone:
Component: wiki | Version: devel
Severity: normal | Resolution:
Keywords: mimetype converter |
--------------------------------+-------------------------------------------
Comment (by Trent Apted <[EMAIL PROTECTED]>):
OK, I've implemented it as a plugin (which can probably migrate to trac-
hacks), so this ticket can probably be closed. But there are some other
issues that implementing this has highlighted. These issues may have
arisen because this 'plugin' is still in essence a hack, and they come in
light of Christian's comment about the duplicated functionality in the
latex formatter vs the html formatter that comes with Trac.
The change from 0.8/0.9 to 0.10 that puts HTML formatting for tickets,
changesets, etc. into the extension architecture --
ExtensionPoint(IWikiSyntaxProvider) and friends -- means that I can no
longer hook into the regex bindings for these the way I could for the
versions of wikilatex implemented for 0.8 and 0.9. So, for now, I have
just disabled them (maybe this is not such an issue for LaTeX, but it
would be nice to have a footnote with the ticket description or changeset
comment, as I did for 0.8). That is, I am no longer using wiki.rules, but
generating my own that don't inlcude those inserted by extensions (which
includes ticket, changeset, etc.):
{{{
#!python
syntax = Formatter._pre_rules[:]
syntax += Formatter._post_rules[:]
helper_re = re.compile(r'\?P<([a-z\d_]+)>')
for rule in syntax:
helpers += helper_re.findall(rule)[1:]
self.myrules = re.compile('(?:' + '|'.join(syntax) + ')')
}}}
(borrowed from [source:trunk/trac/wiki/api.py])
If we want the Formatter logic to be reusable for extensions, then there
might need to be a clean way of overriding these or hooking into the
functionality (maybe there is and I'm missing it). In any case, it quickly
becomes messy because there is no way to anticipate which extensions have
been overridden and will start trying to feed 'Element' objects to the
processor, rather than strings. For wikilatex to work reliably, all of
these would have to be overridden. Also, as Christian points out, the
_parsing_ logic in [source:trunk/trac/wiki/formatter.py Formatter] should
be able to be reused. Maybe this should be a new ticket. On that, after
all this hacking, I am really starting to hate regex. I would suggest a
recursive descent parser to generate a nice parse tree that could be
passed to these content converters, but I don't think the grammar is
context-free so this would have issues.
So where does this ticket stand?
With the current API, I don't think that Formatter can be reused, and for
this plugin to remain maintainable, I feel as though I would have to write
all the parsing logic from scratch. That's fair enough, I suppose, because
inheriting from Formatter is what makes this a hack rather than a plugin,
because I don't think the Formatter is an official API. So, perhaps if I
run out of other work to do or feel like procrastinating, wikilatex will
become the first attempt at implementing the wiki formatter as a recursive
descent parser that can later be incorporated into the core to allow the
parse tree used by other output generators (but I wouldn't be so
presumptuous to suggest that it be used for the main HTML Formatter, which
may be more suited to the regex implementation).
--
Ticket URL: <http://projects.edgewall.com/trac/ticket/2296>
The Trac Project <http://trac.edgewall.com/>
_______________________________________________
Trac-Tickets mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-tickets
