Peter B. West wrote:
> Ok, so how do we drive this thing? Is it zoomable? I couldn't find
> pietsch on there either.
Sorry, I meant to show the path (it took a while to figure out):
Joerg gave us:
http://cvs.apache.org/~sgala/nightmap.html
Then (hoping to find something instructive) look at:
h
J.Pietschmann wrote:
> BTW, I notice the absence of you and Peter from
> http://cvs.apache.org/~sgala/nightmap.html
OK, I should be on there the next time the map is regenerated. Now that you
guys know how to get here, come on over!
Victor Mote
---
J.Pietschmann wrote:
Victor Mote wrote:
BTW, I notice the absence of you and Peter from
http://cvs.apache.org/~sgala/nightmap.html
Ok, so how do we drive this thing? Is it zoomable? I couldn't find
pietsch on there either.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Victor Mote wrote:
I never bit the emacs bullet, and don't directly know the impact there.
GNU emacs 21 knows about UTF-8. Unfortunately, the NT port seems to
be less rock solid than usual, I got the first emacs crashes since
I abandoned Solaris 2.1 in, well, lets say an epoch or two ago.
BTW, I no
Victor Mote wrote:
Peter B. West wrote:
(I wouldn't say it was heated.) I am curious about the impact of
someone working without any formal IDE, and just using (X)Emacs and JDEE
for development. As far as I know, XEmacs does not support Unicode, but
if the non-ASCII characters were restricted t
Peter B. West wrote:
> (I wouldn't say it was heated.) I am curious about the impact of
> someone working without any formal IDE, and just using (X)Emacs and JDEE
> for development. As far as I know, XEmacs does not support Unicode, but
> if the non-ASCII characters were restricted to comments,
Victor Mote wrote:
J.Pietschmann wrote:
OOps, I didn't think about that. We could
a) Force ISO-8859-1 for all Java source files in the build file.
Is this a discrimination of, ummm, non-western contributors
who might want to have their names in their native script
in the files?
b) Keep a
J.Pietschmann wrote:
> OOps, I didn't think about that. We could
> a) Force ISO-8859-1 for all Java source files in the build file.
> Is this a discrimination of, ummm, non-western contributors
> who might want to have their names in their native script
> in the files?
> b) Keep a list
Le Vendredi, 4 juil 2003, à 21:12 Europe/Zurich, J.Pietschmann a écrit :
Bertrand Delacretaz wrote:
Sure - it is by accident that comments in the jfor source code
contains non-ASCII chars (in people's names IIRC).
OOps, I didn't think about that. We could
What I meant is that I think (or rath
Bertrand Delacretaz wrote:
Sure - it is by accident that comments in the jfor source code contains
non-ASCII chars (in people's names IIRC).
OOps, I didn't think about that. We could
a) Force ISO-8859-1 for all Java source files in the build file.
Is this a discrimination of, ummm, non-western
Le Jeudi, 3 juil 2003, à 21:16 Europe/Zurich, J.Pietschmann a écrit :
...And, uh, comment language is *english*, guys :-)
Sure - it is by accident that comments in the jfor source code contains
non-ASCII chars (in people's names IIRC).
No problem in removing the accents!
-Bertrand
--
Christian Geisert wrote:
> > Java source is Unicode, and I don't think the encoding would matter, but
>
> Java source is whatever the platform encoding is (see file.encoding
> system property) so the best thing is to avoid chars > 127 at all
> (use \u instead) ... uh this won't work in this ca
Christian Geisert wrote:
Java source is whatever the platform encoding is (see file.encoding
system property) so the best thing is to avoid chars > 127 at all
(use \u instead) ... uh this won't work in this case as
these are comments. Maybe there's a workaround for special french
characters (l
Victor Mote schrieb:
Bertrand Delacretaz wrote:
[..]
.. Some of the source files contain non-ASCII characters (see
main/JForVersionInfo.java, line 67, for example), but are encoded as
ASCII
(instead of UTF-8), so the IDE was choking...
Are .java files meant to be encoded in UTF-8? I didn't know th
Bertrand Delacretaz wrote:
> > ...Do you
> > mind if I rework that a bit so that the standard header is intact, and
> > then
> > add the additional credits for the jfor team below?...
>
> No problem - I didn't know that checkstyle cared for this as well.
I just committed the changes, leaving (I t
...Do you
mind if I rework that a bit so that the standard header is intact, and
then
add the additional credits for the jfor team below?...
No problem - I didn't know that checkstyle cared for this as well.
-Bertrand
-
To unsub
Bertrand:
Checkstyle is complaining about the Apache license header in the jfor files,
because of the additional credits to the jfor team near the bottom. Do you
mind if I rework that a bit so that the standard header is intact, and then
add the additional credits for the jfor team below? That mig
Bertrand Delacretaz wrote:
> obviously these are needed - sorry about that, I have added them now.
> I'm just fixing the licenses now, but the files are there already.
No apology needed. Thanks for adding them. I have just committed the changes
needed to compile, and have also removed the jfor li
Le Mardi, 24 juin 2003, à 20:27 Europe/Zurich, Victor Mote a écrit :
1. org.jfor.jfor.interfaces (see
rtf/rtflib/rtfdoc/IRtfTableContainer.java,
line 56, for example)
2. org.jfor.jfor.tools (see rtf/rtflib/rtfdoc/RtfExternalGraphic.java,
line
62, for example)
obviously these are needed - sorry a
Victor Mote wrote:
> Bertrand Delacretaz wrote:
> > They don't compile out of the box, so I disabled their compilation in
> > build.xml for now, didn't have time to look further.
> >
> > The next step would be to get them to compile, have the RTFHandler use
> > them and remove jfor.jar from the lib
Bertrand Delacretaz wrote:
> I have committed the classes from the jfor RTF library under
> org.apache.fop.rtf.rtflib.
Thanks.
> They don't compile out of the box, so I disabled their compilation in
> build.xml for now, didn't have time to look further.
>
> The next step would be to get them
On 6/20/2003 9:13 AM, Bertrand Delacretaz wrote:
What's sorely missing IMHO is a way to validate the generated RTF other
than by crashing word processors. If you hear about an RTF validator or
an RTF parser grammar it would be a welcome improvement.
-Bertrand
I don't know if any of these'll help
Hi Victor,
I have committed the classes from the jfor RTF library under
org.apache.fop.rtf.rtflib.
They don't compile out of the box, so I disabled their compilation in
build.xml for now, didn't have time to look further.
The next step would be to get them to compile, have the RTFHandler use
Bertrand Delacretaz wrote:
> If you're going to work on the RTFHandler I'd be happy to commit the
> relevant jfor sources (the RTF library I assume) to the FOP codebase
> with appropriate package name changes.
Yes, I think the RTF libs are the only parts that are needed. I don't want
to mislead a
Hi Victor,
If you're going to work on the RTFHandler I'd be happy to commit the
relevant jfor sources (the RTF library I assume) to the FOP codebase
with appropriate package name changes.
As Jeremias mentions, it might be better if I do it myself so that the
legal stuff is clear.
I should be a
Jeremias Maerki wrote:
> +1 for working on JFOR integration.
>
> If JFOR's sources should go into CVS, I think from the licensing point
> of view, Bertrand will have to do the initial import of the sources. I
> believe, this performs an implicit grant process because of his
> committer license agr
+1 for working on JFOR integration.
If JFOR's sources should go into CVS, I think from the licensing point
of view, Bertrand will have to do the initial import of the sources. I
believe, this performs an implicit grant process because of his
committer license agreement.
Victor, I don't want to dr
27 matches
Mail list logo
