On Mon, Nov 7, 2011 at 1:59 PM, Stuart Rackham <[email protected]> wrote: > > > On 07/11/11 12:08, Dag Wieers wrote: >> >> On Sat, 5 Nov 2011, Stuart Rackham wrote: >> >>> On 05/11/11 09:38, Lex Trotman wrote: >>>> >>>> On 5 November 2011 06:53, Stuart Rackham<[email protected]> wrote: >>> >>> Putting this in the odt conf file should hopefully eliminate the need for >>> the >>> line_break.py filter: >>> >>> [miscellaneous] >>> subsverbatim=specialcharacters,callouts,replacements3 >>> >>> [replacements3] >>> (\n|$)=<text:line-break/>\n >>> \s=<text:s/> >> >> The downside to this last one is that 20 spaces are replaced by 180 >> characters, >> while doing <text:s text:c="20"/> would be better. But I can see how that >> would >> be more difficult to produce. > > It was never going to be pretty to read but if there is a real performance > impact you could first replace in tab sized chunks and then fall back to > single characters: > > [replacements3] > (\n|$)=<text:line-break/>\n > \s{8}=<text:s text:c="8"/> > (?<!<text:s)\s=<text:s/> >
I suspect we can live with this, it will anyway be much faster than running a separate filter. > >> >> >>> The progress to date on the ODF backend is impressive, converting to ODF >>> is a >>> complex business, what I'm not clear on though are the benefits. From >>> what >>> I've read it seems to come down to finding a less complex way of styling >>> PDF >>> output than FOP offers, I'm just not convinced that the cure isn't worse >>> than >>> the disease. >> >> Well, I have to add that in the first 4 hours (doing the ODF back-end) I >> was >> able to do what I couldn't properly do that past 3 years using other >> back-ends. >> That in itself proves to me that this is a viable alternative (for people >> with >> my skills at least). >> >> Also, not just styling and formatting is important to me, for my work I >> need to >> be able to produce (styled) Word and ODF documents too. So it's not just >> about >> producing PDF output (only). >> That is another reason for doing it :) >> [...] >> I hope we can get it to the point where we can include ODF support with >> AsciiDoc >> by default, and I hope we can get your support too ;-) >> > > I've just committed Lex's a2x backend extensions so we're getting there. > > At it's core asciidoc is a tool for generating HTML and DocBook output and > in my opinion it already has to many backends in the distribution (my > primary motivation for the recent plugins, themes and filters support). > > So, for now, I would like to keep ODF support bundled as an external plugin. > The complexity of the ODF backend makes it a great use case for the plugin > architecture. I don't think it matters if its a plugin or core. Not including it (or any backend) with asciidoc though, just forces users to have to install another thing after asciidoc, and I don't see that as worthwhile. On any platform where you are likely to be processing asciidoc (ie one with a reasonable keyboard) the inclusion of all backends, filters, themes etc in the one package is not going to have a material impact. Cheers Lex -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
