I agree - in this case - tokenizing - lexical analysis - is more difficult than parsing.
Best Regards, Jonathan -----Original Message----- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: Wednesday, September 30, 2009 6:25 AM To: email@example.com Subject: Re: Questionable whether font-shorthand grammar LL(1) Thanks everyone for your parser suggestions. I believe we should be able to do without one for the font shorthand, but this is definitely something to keep in mind if we want to improve the parsing of other properties. I’m starting to realise that the most difficult part is probably not so much the grammar parsing as the lexical analysis. To be continued, I guess... Vincent Laurent Caillette wrote: > Hi all, > > I've never used SableCC or JavaCC so I cannot compare, but I'm using ANTLR a > lot. ANTLR is highly customizable and has a very strong community. It's > integrated development environment offers a debugger and visualization of > grammar ambiguities. It's not only simple to setup and use, it also offers > all the comfort you can reasonably dream of when developing grammars. > > Maybe that a tool like JarJar could reduce the pain of depending on one more > library (with all possible conflicts that could happen to FOP users). > > Because code generation has some drawbacks (at least in terms of build > complexity) you may be interested by JParsec, which creates parsers > dynamically from pure Java code. Disclaimer: never used it. > http://jparsec.codehaus.org > > Hope this will help you to do a reasonable choice. > > c. > > > -----Message d'origine----- > De : berger....@gmail.com [mailto:berger....@gmail.com] De la part de Max > Berger > Envoyé : mardi 29 septembre 2009 13:00 > À : firstname.lastname@example.org > Objet : Re: Questionable whether font-shorthand grammar LL(1) > > Hi Vincent, > > > 2009/9/29 Vincent Hennebert <vhenneb...@gmail.com>: >>> How about specifing the grammer and using a tool such as JavaCC to >>> generate the actual parser? This way you could focus more complete >>> grammer and have to spend less time writing the parser. >> That would be the same as using ANTLR. I feel that this is a bit >> overkill for just parsing the font shorthand property, although that may >> prove to be useful for other properties that can accept complex >> expressions. >> That said, JavaCC is an interesting suggestion, I didn’t think of it. If >> a choice had to be made between ANTLR and JavaCC, which one would win? > > ANTLR: > - easy to use > - requires runtime linking of jar  (a *huge* disadvantage imo) > > JavaCC: > - very sparse documentation > - generates standalone java classes > > SableCC: > - better documentation > - LGPL (And therefore maybe not feasible, although it would only be > used at compile time and not runtime) > >  http://beust.com/weblog/archives/000145.html > > > Max