At 02:09 AM 11/6/02, you wrote:
I just went looking in the archives for this discussion & thought I saw
pieces of it, but could not find what I was looking for -- namely, what
theories you guys had proposed / agreed upon. This is related to the font
work that I have started, i.e. I assume that the
On Wed, 2002-11-06 at 08:09, Victor Mote wrote:
> I just went looking in the archives for this discussion & thought I saw
> pieces of it, but could not find what I was looking for -- namely, what
> theories you guys had proposed / agreed upon. This is related to the font
> work that I have started,
Ralph LaChance wrote:
Your comment about progress on the awt viewer is good news -
I'm looking forward to trying it out !
Well, I'm afraid I have to disappoint you, but we have talked about
1.0dev stuff. The viewer's reworking at the moment primary consists of
cleaning the code, removing unnec
Ralph LaChance wrote (to Oleg):
> Some months ago, we exchanged some notes regarding a problem
> in java that leads to a discrepancy in glyph measuring and rendering
> between printing and on-screen viewing. Does your work by any
> chance avoid or resolve those problems ? (For that matter, does
Oleg,
Your comment about progress on the awt viewer is good news -
I'm looking forward to trying it out !
Some months ago, we exchanged some notes regarding a problem
in java that leads to a discrepancy in glyph measuring and rendering
between printing and on-screen viewing. Does your work by a
Jeremias Maerki wrote:
> If it's ok with you, go with font support. I guess you already read
> yourself halfway in and you know my ideas. That would really be great.
> Anything else you might want to take is ok, though, and of course,
> highly appreciated. What are your ideas?
That sounds fine. I
Victor
If it's ok with you, go with font support. I guess you already read
yourself halfway in and you know my ideas. That would really be great.
Anything else you might want to take is ok, though, and of course,
highly appreciated. What are your ideas?
On 04.11.2002 17:33:55 Keiron Liddle wrote:
On Mon, 2002-11-04 at 17:38, Oleg Tkachenko wrote:
> Keiron Liddle wrote:
>
> > The major areas of neglect would have to be:
> > - font handling
> > - api classes
> > - awt viewer
>
> Please, reserve last one for me, I'm almost finishing with it.
Sorry, should have mentioned you are working on i
Keiron Liddle wrote:
The major areas of neglect would have to be:
- font handling
- api classes
- awt viewer
Please, reserve last one for me, I'm almost finishing with it.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
On Mon, 2002-11-04 at 16:19, Victor Mote wrote:
> I'll start in on it right away. If you have a specific task that a greenhorn
> can chew on, please let me know. Otherwise, I'm sure I'll be able to find
> something interesting.
Hi Victor,
The major areas of neglect would have to be:
- font handli
Keiron Liddle wrote:
> That is one of the main problems with the old code, these components are
> all linked together in bad ways, making it hard to improve and deal with
> improvements to any particular part.
> So work on the old code really means using the new code if these are to
> be considere
Jeremias Maerki wrote:
Comments on your thoughts about branches: It sounds like the CVS
manipulation gets to be a project of its own. If it's too complicated,
some won't follow the rules, more work is generated for maintaining the
codebase. That's the impression I get.
It's definitely 1) more c
On 04 Nov 2002 10:05:06 +0100 Keiron Liddle wrote:
> Hi All,
>
> Not sure where to start with all this...
>
> On Mon, 2002-11-04 at 08:34, Jeremias Maerki wrote:
> > Yes, for peripheral components (PDF lib, fonts etc.).
>
> That is one of the main problems with the old code, these components a
On Mon, 2002-11-04 at 09:57, Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > 1.0 as soon as possible. I'm grateful for Victor's work and I hope it
> > won't be a distraction. Because distractions may leave the focus of
> > potential co-developers on the maintenance branch even though the
> > red
On Mon, 2002-11-04 at 09:35, Victor Mote wrote:
> I'll take your word for how it is used in real life, and this perhaps
> explains how we got to the status quo. I just wonder "why?" It seems like
> tagging only the subset of files that need to be different is a much more
> elegant way to handle the
Hi All,
Not sure where to start with all this...
On Mon, 2002-11-04 at 08:34, Jeremias Maerki wrote:
> Yes, for peripheral components (PDF lib, fonts etc.).
That is one of the main problems with the old code, these components are
all linked together in bad ways, making it hard to improve and de
Jeremias Maerki wrote:
> 1.0 as soon as possible. I'm grateful for Victor's work and I hope it
> won't be a distraction. Because distractions may leave the focus of
> potential co-developers on the maintenance branch even though the
> redesign is already quite advanced.
I'm aware that this is a c
Peter B. West wrote:
> Branches generally don't occur with subset of files. The usual
> procedure is to tag a working set of files, then checkout the tag. If
> there are files you don't want in the new working set, delete and 'cvs
> remove' them. Until you 'cvs remove', the comments I made abov
On Mon, 04 Nov 2002 10:22:14 +1000 Peter B. West wrote:
> Jeremias Maerki wrote:
> > Peter
> >
> > This is an idea I was also playing with. Avalon does that, too. But
> > having multiple subprojects (that's what they are, not modules) brings
>
> My sloppy use of the term "module".
>
> > it own
Jeremias Maerki wrote:
Peter
This is an idea I was also playing with. Avalon does that, too. But
having multiple subprojects (that's what they are, not modules) brings
My sloppy use of the term "module".
it own difficulties. There are several pros and cons to this:
+ Encourages loose coupling
Victor Mote wrote:
Peter B. West wrote:
Re some recent questions on this topic. As I understand it, creating a
branch in the tree off an existing file set simply involves tagging the
set of files with the new branch tag. From that point on, as long as a
particular file remains unchanged, a ch
Peter B. West wrote:
> Re some recent questions on this topic. As I understand it, creating a
> branch in the tree off an existing file set simply involves tagging the
> set of files with the new branch tag. From that point on, as long as a
> particular file remains unchanged, a checkout on eith
Jeremias Maerki wrote:
But please, let's put our
efforts together to bring FOP to a version 1.0 as soon as possible. A
lot is already there. We can build on that.
That's what I wanted to say all the thread, +1.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
-
Peter
This is an idea I was also playing with. Avalon does that, too. But
having multiple subprojects (that's what they are, not modules) brings
it own difficulties. There are several pros and cons to this:
+ Encourages loose coupling and good design
+ Components that could in theory be used indep
Re some recent questions on this topic. As I understand it, creating a
branch in the tree off an existing file set simply involves tagging the
set of files with the new branch tag. From that point on, as long as a
particular file remains unchanged, a checkout on either branch will
retrieve a
25 matches
Mail list logo
