headers
Bertrand Delacretaz | 1 Nov 2002 07:53
Picon
Gravatar

[FYI] jfor integration jumpstarted...

I have added jfor-0.7.1.jar and its license to the lib subdirectory, and 
created a first version of an RTFHandler that outputs (very rough) RTF 
documents using the existing jfor RTF library [1].

"build.sh examples" now generates RTF documents, assuming the following is 
set in build-local.properties in the directory that contains build.xml:

  # output format for "ant examples"
  build.property.examples.mime.type = rtf

I probably won't work on this over the weekend (I'll be building the music 
room instead ;-), so if anyone wants to have a shot at improving it, go for 
it! 
Examples of how to use the jfor RTF library can be found in the 
org.jfor.jfor.converter package of jfor, see www.jfor.org.

-Bertrand

[1] as already discussed here, this is done so as to avoid having to maintain 
two RTF libraries until FOP is better than jfor at generating RTF
Permalink | Reply | 0 comments |
headers
bugzilla | 1 Nov 2002 13:44
Picon
Favicon

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

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161

[PATCH] add translation to GoToPageDialog

           Summary: [PATCH] add translation to GoToPageDialog
           Product: Fop
           Version: 0.20.4
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: awt renderer
        AssignedTo: fop-dev <at> xml.apache.org
        ReportedBy: BuchtikM <at> dlsystem.cz

There are hard-coded strings in GoToPage dialog, this patch correct it.
I post the updated czech translation resource too.

Michal Buchtik
BuchtikM <at> dlsystem.cz
Permalink | Reply | 0 comments |
headers
bugzilla | 1 Nov 2002 13:45
Picon
Favicon

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
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161

[PATCH] add translation to GoToPageDialog

------- Additional Comments From BuchtikM <at> dlsystem.cz  2002-11-01 12:45 -------
Created an attachment (id=3691)
patched GoToPageDialog.java
Permalink | Reply | 0 comments |
headers
bugzilla | 1 Nov 2002 13:46
Picon
Favicon

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
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161

[PATCH] add translation to GoToPageDialog

------- Additional Comments From BuchtikM <at> dlsystem.cz  2002-11-01 12:46 -------
Created an attachment (id=3692)
patch file for  PreviewDialog.java
Permalink | Reply | 0 comments |
headers
bugzilla | 1 Nov 2002 13:47
Picon
Favicon

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
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161

[PATCH] add translation to GoToPageDialog

------- Additional Comments From BuchtikM <at> dlsystem.cz  2002-11-01 12:47 -------
Created an attachment (id=3693)
new resources.cs file
Permalink | Reply | 0 comments |
headers
Keiron Liddle | 1 Nov 2002 16:51

RE: handling patches

Hi Victor,

I'm lost for ideas.
I'm getting the feeling that this project is simply too large for this
situation. Which is why I want the effort to be focused and not wasting
time sorting out things that don't get us anywhere.

On Thu, 2002-10-31 at 20:30, Victor Mote wrote:
> I realize that I am jumping into this conversation in the middle. I am
> ignorant of the history of how we got where we are, so **please** understand
> that I am not being critical. My first exposure to an open-source project
> was when I started monitoring this list on July, and I have no idea how
> other projects operate. However, I have done some reading on the subject,
> and my reading generally agrees with my own intuition. I think we are in
> danger of violating a cardinal principle of open source development, and
> indeed of software development in general -- that you operate as much as
> possible with code that works. Unless you have massive amounts of resources
> (and probably there as well), the only model of software development that
> seems to work is an immediate feedback loop. The sequence is
> 1) recognize a need, 2) implement (plan and code), 3) test, 4) answer the
> question, "Is the code better with this than it was before?" 5) iff "yes",
> check it in.

That sounds very good and is probably works almost all the time. The
fact is that it was not working.

And as they say, "It seemed like a good idea at the time". Circumstances
change and we need to deal with what is now.

Actually projects like mozilla have branches for maintanence but the key
(Continue reading)

Permalink | Reply | 20 comments |
headers
Peter B. West | 2 Nov 2002 00:49
Picon
Picon

Re: handling patches

Keiron Liddle wrote:
> Hi Victor,
> 
> I'm lost for ideas.
> I'm getting the feeling that this project is simply too large for this
> situation. Which is why I want the effort to be focused and not wasting
> time sorting out things that don't get us anywhere.

It's a big task.  Tangentially speaking, I still haven't finished work 
on properties, but as I proceed, I get more insight into the existing 
design and implementation, and more respect for it.  A newcomer has no 
shortcuts to this situation.  There's a Catch-22 here for complex open 
source projects.  Resources are, by definition, in short supply.  No 
matter what your working environment, the first thing to suffer from 
such shortages is documentation.  But open source needs documentation 
(and the panoply of skills transfer mechanisms) more than a normal project.

....

> The only realistic merge that I can see is bringing across the following
> to the branch:
> - pdf lib
> - svg
> - image handling
> 
> maybe
> - renderers
> - area tree
> 
> There isn't really that much on the branch that is relevant to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Victor Mote | 2 Nov 2002 09:56

RE: handling patches

Keiron Liddle wrote:

> Actually projects like mozilla have branches for maintanence but the key
> is that they are short lived, this didn't work out like that.

I don't know this, but I'll bet that the maintenance branch that you refer
to here is for bug fixes, while the main development line progresses
*incrementally* on the trunk. The reason why ours didn't work out that way
(I suspect) is because we tried to do a chasm-type change on the trunk,
where we had to break the code to go forward. With 20/20 hindsight, it is
easy to see that the chasm change would have been more convenient to manage
on a branch. In this respect, it is no different from a normal patch. For a
normal patch, your sandbox is a kind of branch. Only after the code is
completed and tested do you commit it. The only difference with a chasm-type
change is that, because it is so big, you want to be able to put incremental
changes into source code control so that can keep a history. The principle
still remains that only after it is completed and tested should it be merged
(committed, if you will) to the trunk. As you correctly point out elsewhere,
this is all water under the bridge. I mention it only because I suspect that
it explains the difference with mozilla.

> I think you have misunderstood something. There has been a great number
> of changes across many packages and classes in trunk. The reason being
> that the code was (and still is in the branch) in a bad way, this
> occured gradually more because it wasn't prevented from hapenning.
> For example the link support, pdf library, image handling.
> It becomes quite obvious when you understand why there are so many bugs
> with link positioning, image handling and further causes of memory
> leaks, excess memory usage.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Victor Mote | 2 Nov 2002 10:35

RE: handling patches

Victor Mote wrote:

> If it is not feasible to unify significant portions of the two branches,
> either by switching them in the repository or by putting them into one
> branch, then I propose that we clarify our terminology by using the term
> "rewrite" instead of "redesign". This would signal that we are not merely
> rebuilding an important module, but that the changes are
> pervasive, and that
> the old code has been effectively abandoned.

Upon further consideration, I would also recommend that, in the above case,
we actually put the code into two different projects. Branches imply
eventual merging, and I think that is part of what has been confusing me. By
cutting that tie, it would be clear that there will be no merging. Right
now, we are kind of half in and half out, and it would be good to signal
whatever decision is reached definitively, mostly for the benefit of those
of us (me) who are slow to catch on.

Victor Mote
Permalink | Reply | 13 comments |
headers
Bertrand Delacretaz | 2 Nov 2002 12:24
Picon
Gravatar

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

On Saturday 02 November 2002 10:35, Victor Mote wrote:
>. . .I would also recommend that, in the above case,
> we actually put the code into two different projects. 
>. . .

+1, I like the idea.

How about moving the "new" code (HEAD) to a separate (xml-fop2) CVS project 
to clarify things, and maybe name the new version "fop 2" instead of 1.0x?

Although the current version is 0.20.x, it *is* used in production at a 
number of sites, so going directly to version 2.x for a mostly new codebase 
makes sense IMHO.

-Bertrand
Permalink | Reply | 4 comments |

Gmane