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 th
Hi Jonathan,
Jonathan Levinson wrote:
> Hi Vincent,
>
> Excellent ideas!
>
> The diagram you drew is extremely useful!
>
> If the font shorthand sub-language has a grammar that is regular then it also
> has a grammar that is LL(1). So recursive descent parsing will work, if
> there is a re
Hi Vincent,
> I see. I had in mind to use OpenTypeDataInputStream as the common
> interface. It actually makes sense to use ImageInputStream instead.
> Simpler and just as flexible. That will add a direct dependency on
> a class in the javax.imageio package, but this is not a problem as it is
> pa
Hi Max,
First, I will respect every code style of FOP. Its just a matter of
discussion.
> > Really? That means commenting every public method even simple Getters
> > and Setters?
>
> Yes. Simple Getter and Setters are the only place where you can
> publicly document private variables. (in most c
Hi,
I am not sure on the licensing part as sebastian did some changes in FOP
code and he provided me the jars. And as per what i had checked those jar
print arabic correctly.
Possibly he will only be able to answer and I am nots ure whether the change
was made keeping FOP standards. He was pl
Hi Vincent,
> Speaking of that, there’s a rule that I would suggest to disable: the
> HiddenFieldCheck. I don’t really see its benefit. It forces to find
> somewhat artificial names for variables, where the field name is exactly
> what I want. Sometimes a method doesn’t have a name following the
>
Hi Max,
> > Speaking of that, there’s a rule that I would suggest to disable: the
> > HiddenFieldCheck. I don’t really see its benefit. It forces to find
> > somewhat artificial names for variables, where the field name is exactly
> > what I want. Sometimes a method doesn’t have a name following t
Hi Alexander,
Alexander Kiel wrote:
> Hi Vincent,
>
>> I see. I had in mind to use OpenTypeDataInputStream as the common
>> interface. It actually makes sense to use ImageInputStream instead.
>> Simpler and just as flexible. That will add a direct dependency on
>> a class in the javax.imageio pac
Hi Alexander,
Alexander Kiel wrote:
> Hi Max,
>
> First, I will respect every code style of FOP. Its just a matter of
> discussion.
>
>>> Really? That means commenting every public method even simple Getters
>>> and Setters?
>> Yes. Simple Getter and Setters are the only place where you can
>> p
Hi Vincent,
> Should the rule be disabled because of that? Having proper javadoc on at
> least public methods is very important. OTOH, this is actually not
> something Checkstyle can verify. How many methods in the code base have
> totally useless comments that are there just to avoid a Checkstyle
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: fop-dev@xmlgraphics.apache.org
Subject: Re: Questiona
Hello,
Jeremias Maerki-2 wrote:
>
> I've written some code that can embedd a single-stripe CMYK TIFF in PDF
> as a proof of concept. I've done it for PDF because that was the easiest
> to implement. I don't want to commit that right now since it
> would need a lot of testing first. So in case I
Quoting Prakash sen :
Hi,
I am not sure on the licensing part as sebastian did some changes in FOP
code and he provided me the jars. And as per what i had checked those jar
print arabic correctly.
Possibly he will only be able to answer and I am nots ure whether the change
was made keeping
13 matches
Mail list logo
