configuration and CVS branches
I have downloaded the FOP's main branch and I have built it successfully.
After playing with the PDFTranscoder (only, no FOP) for several days I
wanted to take the next step and try to add some custom fonts. I traced
through the code and I think I need to prov
I have downloaded the FOP's main branch and I have built it successfully.
After playing with the PDFTranscoder (only, no FOP) for several days I
wanted to take the next step and try to add some custom fonts. I traced
through the code and I think I need to provide a configuration class which
imple
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
On Fri, 2002-10-25 at 18:08, Patrick Dean Rusk wrote:
> I've recently started working with FOP, and I gather from this list that
> there are multiple CVS branches of code, in particular for the new design
> and for the upcoming 0.20.5. I gather from the "fop-cvs"
a re-working of properties handling,
so far.
Peter
Patrick Dean Rusk wrote:
I've recently started working with FOP, and I gather from this list that
there are multiple CVS branches of code, in particular for the new design
and for the upcoming 0.20.5. I gather from the "fop-cvs"
I've recently started working with FOP, and I gather from this list that
there are multiple CVS branches of code, in particular for the new design
and for the upcoming 0.20.5. I gather from the "fop-cvs" messages that at
least one of these is called "FOP_0-20-0_Alt-D
Keiron Liddle wrote:
>
> Confusion abounds!
>
It does indeed. 8)
> The trunk is also known as: "HEAD", "MAIN", main, development, redesign
> or even "cvs update -A" or "cvs update -rHEAD"
Okay, thanks for clearing that up. My confusion arose from the fact that
ViewCVS (which is used by cv
Confusion abounds!
There are only two (2) FOP cvs things.
THe is the trunk and the maintanence branch.
The maintanence branch has the name "fop-0_20_2-maintain". This is for
maintanence releases.
The trunk is also known as: "HEAD", "MAIN", main, development, redesign or
even "cvs update -A"
Christian Geisert wrote:
>
> I assumend MAIN and HEAD are equivalent ...
> (Maybe someone can explain this to me ;-)
Not in FOP.. 8)
> If you checkout FOP without a given branch you get the main development
> branch (aka redesign).
Yeah, that's the case. This is usually called "the trunk", a
Michael Gratton wrote:
>
> Guys,
>
> Sorry to reshash what is probably an old and tired subject, but I've
> gotten some conflicting advice as to what CVS branch is used for what.
> If anyone could help fill in the blanks and correct the errors, I'd
> appreciate it. 8)
I'll try it (but I'm no
Guys,
Sorry to reshash what is probably an old and tired subject, but I've
gotten some conflicting advice as to what CVS branch is used for what.
If anyone could help fill in the blanks and correct the errors, I'd
appreciate it. 8)
"MAIN" -> FOP redesign / new-design branch. This is where de
35 matches
Mail list logo
