Re: When to release 1.0?

[Jeremias Maerki]

I've updated the ReleasePlanning page. ATM, I've simply changed it to
what I read from this thread. Please, everyone, help sorting out the
details so we can decide where to go.

On 19.06.2006 10:31:15 Jeremias Maerki wrote:

> > So maybe we need a feature freeze and bug fixing period?
> 
> Not only that. We need a Wiki page listing all issues everyone wants to
> see fixed/handled before a 1.0 release. We can then decide on which
> subset we are really going to process. Otherwise, we won't finish before
> 2007.
> 
> There was http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning. I
> suggest we streamline that page and bring it up to date again, so we
> have a single point to look at to track the progress towards 1.0.




Jeremias Maerki

Re: When to release 1.0?

[Jeremias Maerki]

On 19.06.2006 11:35:18 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> > On 18.06.2006 13:26:00 Manuel Mall wrote:
> 
> 
> 
> >>
> >>Calling a release 1.0 is IMO quite a significant step which shouldn't 
> >>been taken lightly. What we are saying in doing so is: Here is 
> >>something we believe is ready for production use.
> > 
> > 
> > Yes, but neither should we put off a 1.0 for much longer. Having a 0.x
> > version number is a big disadvantange. OTOH, when I released Barcode4J
> > 1.0 it was almost too perfect. Almost no serious problems and also
> > almost no third-party patches. No community building. One-man show. :-(
> 
> I don't think you can compare Barcode4J to FOP. FOP is a much bigger and 
> more complex system.

Sure, it's bigger, but my point was about community building. And that
doesn't have so much to do with the size of a project. The question is:
What makes someone decide to help out in a project and send patches?
That's a very important question we have to ask ourselves. We still need
to attract new people. For example, all those tool producers lurking on
this list and/or using Apache FOP in their products. I'm in contact with
some of them. Pretty much everyone says they are interested but still
most of them hold back. Some because they are still stuck with 0.20.5
(many have customized 0.20.5 versions). Frankly, I'm stumped as to why
they don't even give their opinions where they would like to see FOP
head. I'd like to find out what we can do to encourage them to join us.
So far, I have no recipe. At least, I'm happy to have some supporters
who enabled me to allocate so much time to FOP in the last 18 months,
even if some of them choose to stay in the background. Still, given
FOP's popularity and the progress we made in the past months, I'm
surprised we don't get more supporters. But as you say, a 1.0 will
certainly have a big boost in this direction. What else can we do?

At this point, I want to say a big thank-you to the Swiss Federal
Insitute of Intellectual Property which supported me to fix several bugs
and to implement some layout enhancements and support for PDF/A-1b,
PDF/X-3:2003, fixed-width spaces and kerning. And of course, a huge
thank-you to my biggest supporter who enabled me to help bring FOP to
where it is today!



> Please can you say where you think 0.92beta is behind 0.20.5? The only 
> issue that I'm aware of is the change of IPD mid-page-sequence.

I've listed them in http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
I was a little surprised. It's not just 2 or 3 items.




Jeremias Maerki

fop question

[SerapH .]

hi,,my OS is windowsxp ,chinese simplied version,today i test fop-0.20.5
and covent   \fop-0.20.5\examples\fo\advanced\cid-fonts.fo  to pdf,but the chinese and japanese can't convent correct,
can you tell me why ?? 
and how can i convent it rightthanks very much.
 
the java program i use fop-0.20.5\examples\embedding\java\embedding\ExampleFO2PDF.java
 
 
 


ResultFO2PDF.pdf
Description: Adobe PDF document

Re: When to release 1.0?

[Chris Bowditch]

Jeremias Maerki wrote:



Please can you say where you think 0.92beta is behind 0.20.5? The only 
issue that I'm aware of is the change of IPD mid-page-sequence.



I've listed them in http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
I was a little surprised. It's not just 2 or 3 items.



Thanks for that. It isnt too bad IMHO. Although I remembered another one 
you missed off. I've added some feedback on the other issues in the Wiki.


Chris

Re: keep...="always" and Knuth penalties

[Luca Furini]

Jeremias Maerki wrote:


> On 19.06.2006 15:45:36 Luca Furini wrote:
> It seems to me that the prescribed behaviour requires a keep constraint 
> with force = "always" to be satisfied *always* :-), even if this would 
> mean having some overflowing content. 


Obviously, we disagree here. I read it so that "always" can also be
relaxed if the keep cannot be satisfied. Did anyone check what other
implementations do?


A quick test shows that AntennaHouse's xslformatter satisfies all the 
keeps, even when this means having some content overflow the body region 
(the overflowing content is actually clipped), while RenderX's xep relaxes 
a keep constraint in order to avoid overflows.


So, it seems the match is still a draw! ;-)

Regards
Luca

Re: keep...="always" and Knuth penalties

[Chris Bowditch]

Luca Furini wrote:


Jeremias Maerki wrote:


> On 19.06.2006 15:45:36 Luca Furini wrote:
> It seems to me that the prescribed behaviour requires a keep 
constraint > with force = "always" to be satisfied *always* :-), even 
if this would > mean having some overflowing content.

Obviously, we disagree here. I read it so that "always" can also be
relaxed if the keep cannot be satisfied. Did anyone check what other
implementations do?



A quick test shows that AntennaHouse's xslformatter satisfies all the 
keeps, even when this means having some content overflow the body region 
(the overflowing content is actually clipped), while RenderX's xep 
relaxes a keep constraint in order to avoid overflows.


So, it seems the match is still a draw! ;-)


Well I have to agree with Jeremias here. It makes more sense from a 
business documents POV to avoid overflowing content at all costs! keeps 
should be relaxed if content cannot be made to fit and a warning issued 
to the log to tell the user.


Chris

DO NOT REPLY [Bug 39840] - Multi page table fails with an endless loop error message

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=39840


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2006-06-20 19:35 ---
The document is littered with keeps. You don't give FOP a chance to break
anywhere. The worst of them is the keep-together on the block surrounding the
table. The table is longer than a page. That's why FOP fails. We're currently
discussing relaxing the keep conditions for these situations but the spec is a
little ambiguous about this. What you can do now is remove that keep-together
and let the table break. It has nothing to do with auto table layout. It's just
our current interpretation of the FO spec that may need to be revised.

Unless anybody objects I'll leave the bug open as an additional reminder for us
to go after this phenomenon. Funny coincidence anyway, that you file this entry
while we're already discussing the very problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 39846] New: - Style in comments

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=39846

   Summary: Style in comments
   Product: Fop
   Version: all
  Platform: Other
OS/Version: other
Status: NEW
  Severity: trivial
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Just me being a nitpicker...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 39846] - Style in comments

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=39846





--- Additional Comments From [EMAIL PROTECTED]  2006-06-20 20:57 ---
Created an attachment (id=18491)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18491&action=view)
The SVN diff


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 39847] New: - Small mistake in conventions.xml page

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=39847

   Summary: Small mistake in conventions.xml page
   Product: Fop
   Version: all
  Platform: Other
OS/Version: other
Status: NEW
  Severity: trivial
  Priority: P5
 Component: documentation
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Developers submitting patches are encouraged to follow the code conventions to
reduce the work load on THE THE committers

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 39847] - Small mistake in conventions.xml page

[bugzilla]

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://issues.apache.org/bugzilla/show_bug.cgi?id=39847





--- Additional Comments From [EMAIL PROTECTED]  2006-06-20 21:06 ---
Created an attachment (id=18492)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18492&action=view)
Corrects the small mistake in conventions.xml


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: When to release 1.0?

[J.Pietschmann]

Jeremias Maerki wrote:

Ok, if we want that 1.0 won't be out before September.


Too bad. As already mentioned, changing IPD page masters worked
reasonably well in 0.20.5 and I think people will expect this to
work in a 1.0 release too.

OTOH, if the frequency of questions on the lists are taken into
account, support for collapsing table borders, even if only partial,
has a much higher priority. I don't see any of the other mentioned
features as a show stopper for 1.0.


That remark comes pretty late, but yeah, if anyone else think this
should be fixed, we should do it SOON.


Well, someone should have looked at this before (I made some style
related notes during the API discussion).
The guide lines are
- consistency with the Java RTL identifier guide lines, in particular
 the rule that common acronyms in identifiers are all upper case
- internal consistency
- avoiding redundancy
We can restrict this to the essential user visible API, i.e.
the packages o.a.fop.apps and o.a.fop.cli.

My suggestions
- Rename o.a.fop.apps to o.a.fop.api. This is a major change breaking
  everything, and should have been done in the same step when the
  Driver was replaced by the Fop class. I wont insist on this change.
- If the "Fop" in FopFactory is the acronym for "FO processor", the
  class should be named FOPFactory instead. Same for Fop --> FOP
  (precedent is the java.net.URL class).
- If it's the other way around FOPException should be renamed as
  FopException.
- MimeConstants should be renamed as MIMEConstants.
- FOURIResolver should probably be renamed as plain URIResolver (the FO
  prefix may be deemed redundant because of the package), or as
  FOPURIResolver. Two consecutive acronyms in an identifier are awkward
  in any case.
- Same for FOUserAgent --> UserAgent or FOPUserAgent
- The method applyHttpBasicAuthentication should be renamed
  applyHTTPBasicAuthentication.
- Rename the CLI parameter "-param" to "-xsltparam" or something (too
  generic)
We could keep and deprecate the unrenamed classes in order to ease the
transition. If the API is really declared "stable", the beta tag can
be dropped from the release number even for a pre 1.0 release.

Should we hold a formal vote on the API style issue? Either way, I'd
even volunteer to do the changes (it's easy enough :-).

J.Pietschmann

Re: When to release 1.0?

[Jeremias Maerki]

Joerg,

I'm glad you volunteer to do any changes. But there's also something
else. We had a vote in March about merging back the "API Finalization"
branch back into Trunk. You voted +1 back then knowing the the branch
had the word "Finalization" in it. Furthermore, we've already
communicated with 0.92beta that "the API is now considered stable" [1].
So, if the committership feels we should take another round of API
improvements, I won't block (your suggestions are all reasonable) but I
won't take the lead here. Either you or someone else has to take the
lead and push for it (consensus gathering, changes, documentation,
communication...).

I'm leaving tomorrow for Ireland and will be away for another week after
ApacheCon on "green holidays" (Swiss style), so I wouldn't have time
anyway. But I'll try to keep an eye on the lists as often as possible.

[1] http://xmlgraphics.apache.org/fop/0.92/upgrading.html

On 20.06.2006 23:24:15 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Ok, if we want that 1.0 won't be out before September.
> 
> Too bad. As already mentioned, changing IPD page masters worked
> reasonably well in 0.20.5 and I think people will expect this to
> work in a 1.0 release too.
> 
> OTOH, if the frequency of questions on the lists are taken into
> account, support for collapsing table borders, even if only partial,
> has a much higher priority. I don't see any of the other mentioned
> features as a show stopper for 1.0.
> 
> > That remark comes pretty late, but yeah, if anyone else think this
> > should be fixed, we should do it SOON.
> 
> Well, someone should have looked at this before (I made some style
> related notes during the API discussion).
> The guide lines are
> - consistency with the Java RTL identifier guide lines, in particular
>   the rule that common acronyms in identifiers are all upper case
> - internal consistency
> - avoiding redundancy
> We can restrict this to the essential user visible API, i.e.
> the packages o.a.fop.apps and o.a.fop.cli.
> 
> My suggestions
> - Rename o.a.fop.apps to o.a.fop.api. This is a major change breaking
>everything, and should have been done in the same step when the
>Driver was replaced by the Fop class. I wont insist on this change.
> - If the "Fop" in FopFactory is the acronym for "FO processor", the
>class should be named FOPFactory instead. Same for Fop --> FOP
>(precedent is the java.net.URL class).
> - If it's the other way around FOPException should be renamed as
>FopException.
> - MimeConstants should be renamed as MIMEConstants.
> - FOURIResolver should probably be renamed as plain URIResolver (the FO
>prefix may be deemed redundant because of the package), or as
>FOPURIResolver. Two consecutive acronyms in an identifier are awkward
>in any case.
> - Same for FOUserAgent --> UserAgent or FOPUserAgent
> - The method applyHttpBasicAuthentication should be renamed
>applyHTTPBasicAuthentication.
> - Rename the CLI parameter "-param" to "-xsltparam" or something (too
>generic)
> We could keep and deprecate the unrenamed classes in order to ease the
> transition. If the API is really declared "stable", the beta tag can
> be dropped from the release number even for a pre 1.0 release.
> 
> Should we hold a formal vote on the API style issue? Either way, I'd
> even volunteer to do the changes (it's easy enough :-).
> 
> J.Pietschmann



Jeremias Maerki