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
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 regular
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
part
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 cases,
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
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 the
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 package, but
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
publicly
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:
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 prakash@gmail.com:
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
13 matches
Mail list logo
