DO NOT REPLY [Bug 13310] - [PATCH] javadoc build errors & warnings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Line ending chaos in our codebase

Thanks, Peter and Betrand, for your answers. On Tue, 5 Nov 2002 07:21:54 +0100 Bertrand Delacretaz wrote: > On Monday 04 November 2002 17:02, Jeremias Maerki wrote: > >. . .Does anyone have a good idea how to... > > 2. enforce correct line endings? > > Using the commitinfo administrative file, sc

Re: Line ending chaos in our codebase

On Monday 04 November 2002 17:02, Jeremias Maerki wrote: >. . .Does anyone have a good idea how to... > 2. enforce correct line endings? Using the commitinfo administrative file, scripts can be configured in CVS to run when a file is committed, at which point you could detect the problem. I'm n

Re: Line ending chaos in our codebase

On Monday 04 November 2002 23:53, Peter B. West wrote: >. . .I don't know the > mechanism for handling line-end differences on entry into a CVS > repository on a unix box. >. . . AFAIK as long as the "binary file" flag is not set, CVS takes care of line endings by itself when a file is checked

RE: Common code in CVS branches

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

Re: Line ending chaos in our codebase

Jeremias, Never having had the misfortune to work with Windows, I don't know the mechanism for handling line-end differences on entry into a CVS repository on a unix box. I assume you have to handle this on your end, because I occasionally see files with CRLF out of CVS repositories. Is this

Re: Common code in CVS branches

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:

Current status of re-design

I've been following this list for a few weeks now, but I'm still unclear as to the current status of the re-design efforts. The FOP Web site's "status" page hasn't been updated since June, apparently, when the estimate of being 35% done was issued. Anyone want to take a stab at sa

Re: where to start knowing about fop code

Sridhar Velagapudi wrote: I m new bie in this Fop project. I just want to know what is the start point in Fop project and how it goes. can any body help me to start with? thanks in advance. There is a directory docs/html-docs in your FOP distribution. Start there. J.Pietschmann -

where to start knowing about fop code

Hi all, I m new bie in this Fop project. I just want to know what is the start point in Fop project and how it goes. can any body help me to start with? thanks in advance.   SriGet faster connections -- switch to MSN Internet Access! Click Here --

Re: Common code in CVS branches

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

Re: Common code in CVS branches

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

RE: Common code in CVS branches

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

cvs commit: xml-fop/docs/examples/fo extensive.fo leader.fo

keiron 2002/11/04 08:31:20 Modified:docs/examples/fo extensive.fo leader.fo Log: improved examples a bit Revision ChangesPath 1.17 +8 -6 xml-fop/docs/examples/fo/extensive.fo Index: extensive.fo ===

place for patches

Where would be a good place to put some patches. I have current cvs working with cocoon+forrest and have a patch to work with the fop-block and a patch to make bookmarks in the pdf output. Really basic stuff but it might be useful to someone. ---

cvs commit: xml-fop build.sh

jeremias2002/11/04 08:05:09 Modified:.Tag: fop-0_20_2-maintain build.sh Log: Bugzilla Entry 13310 Improved classpath construction Submitted by: Victor Mote <[EMAIL PROTECTED]> Revision ChangesPath No revision No revi

Line ending chaos in our codebase

Hi there Before I'm going to work on the multi-threading issues I wanted to clear up a few patch submissions. While applying them I ran across several files that had CRCRLF endings instead of CRLF when checked out using WinCVS on a Windows box. I think I have successfully corrected those I ran int

DO NOT REPLY [Bug 14057] - [PATCH] implement "text-transform"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 13919] - [Patch] Font Refactor, phase 1, maintenance branch

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Common code in CVS branches

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

cvs commit: xml-fop/src/org/apache/fop/datastructs Node.java TreeException.java Tree.java

pbwest 2002/11/04 07:17:10 Modified:src/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design Tree.java Added: src/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design Node.java TreeException.java Log: Node and TreeException e

DO NOT REPLY [Bug 14161] - [PATCH] add translation to GoToPageDialog

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-fop/src/org/apache/fop/viewer/resources resources.cs resources.de

jeremias2002/11/04 07:14:33 Modified:src/org/apache/fop/viewer Tag: fop-0_20_2-maintain GoToPageDialog.java PreviewDialog.java src/org/apache/fop/viewer/resources Tag: fop-0_20_2-maintain resources.cs resources.de Log: Bu

cvs commit: xml-fop/src/org/apache/fop/fo FONode.java FoRoot.java

pbwest 2002/11/04 06:54:56 Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FONode.java FoRoot.java Log: Node and TreeException extracted from Tree. Revision ChangesPath No revision No revision

cvs commit: xml-fop/src/org/apache/fop/fo/pagination FoLayoutMasterSet.java FoPageSequenceMaster.java FoRegionAfter.java FoRegionBeforeAfter.java FoRegionBefore.java FoRegionBody.java FoRegionEnd.java FoRegionStartEnd.java FoRegionStart.java FoSimplePageMaster.java

pbwest 2002/11/04 06:46:03 Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design FoLayoutMasterSet.java FoPageSequenceMaster.java FoRegionAfter.java FoRegionBeforeAfter.java FoRegionBefore.java FoRegi

RE: handling patches (how about "fop 2")

Here is one other point to consider: if you expect the redesign when complete to perform at at least the same level, i.e. with the same coverage of the specification and as many or fewer defects, when it comes "online" and replaces the current maintenance release, then I imho the project should c

Re: Common code in CVS branches

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

cvs commit: xml-fop/src/org/apache/fop/fo/pagination PageSequence.java

keiron 2002/11/04 03:50:11 Modified:src/org/apache/fop/layoutmgr PageLayoutManager.java src/org/apache/fop/fo/pagination PageSequence.java Log: page numbering across sequences and number formatting Revision ChangesPath 1.22 +20 -7 xml-fop/src/org/

RE: handling patches

On Sat, 2002-11-02 at 21:31, Victor Mote wrote: > I agree that maintenance branches are not obliged to be merged eventually, > but you still have not shown any benefit to keeping them in the same tree if > they are not. > > Usual development pattern would also be that someone makes sure that new >

Re: Common code in CVS branches

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

RE: Common code in CVS branches

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

RE: Common code in CVS branches

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

Re: Common code in CVS branches

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

RE: Common code in CVS branches

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

RE: Common code in CVS branches

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