DO NOT REPLY [Bug 25803] - [PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25803

[PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty





--- Additional Comments From [EMAIL PROTECTED]  2004-01-01 00:20 ---
Alt-Design addresses this problem by the simple expedient of processing
properties in integer property number order.

DO NOT REPLY [Bug 25803] - [PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25803

[PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 21:26 ---
Ouch, it is Finn who made this remark. Well, over to Glen then.

Simon

DO NOT REPLY [Bug 25803] - [PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25803

[PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 21:24 ---
Glen,

attr_done local: Indeed, that would have been better.

use getExplicitBaseProp(): OK.

Do you expect a modified patch, or do you make the change to getExplicitBaseProp()?

Thanks, Simon

Re: Output from NIST test suite

[Carmelo Montanez]

Hi Folks:

Somehow the final copy of the test suite was not uploaded to either our
server at NIST or W3C.  I uploaded a copy of the latest suite version
to the following link:
http://xw2k.sdct.itl.nist.gov/carmelo/formattingObjectsSuite123103.zip

I will make sure it is at the W3c and NIST server soon.

Thanks,
Carmelo
At 04:12 PM 12/25/2003 +0100, you wrote:
Hi,

After 'fixing' the master-reference issue in my copy of the NIST test 
suite, I ran the tests against 0.20.5 and 1.0dev and merged the result 
side by side into a single .pdf file.

You can download the result (1Mb) here:

   http://bckfnn-modules.sf.net/out-0.20.5-1.0.pdf

For some reason the pdf does not display correctly in my browsers, so it 
is better to download it. The merged pdf file is created using iText.

The square to the left contains the output from 0.20.5 and the square on 
the right the output from HEAD.

Here is also a merge between the pdf files that comes with the NIST suite 
and head:

   http://bckfnn-modules.sf.net/out-nist-1.0.pdf

There is still a few issues left to fix .

Another way of using the test suite could be to compare a binary image of 
the pages against some kind of reference. Has such a approach been tried? 
Does anyone know of available software that can render a PDF as an image file?

regards,
finn

Re: [VOTE] Clay Leeds for committer

[Clay Leeds]

I appreciate the nod from fop-dev team for my nomination. It came as a 
very pleasant surprise to me. I've been waiting for the VOTE to pan out 
before making comments. In any case, my intention is to continue on the 
same path of learning and service as before.

Web Maestro Clay

On Dec 28, 2003, at 6:38 AM, Jeremias Maerki wrote:
In recognition for his contributions to this project I'd like to 
propose
"Web Maestro" Clay Leeds as a FOP committer. He's active on both dev 
and
user mailing lists for at least 1 year now. He's actively helping out 
on
the user mailing list and as our favourite nit-picker :-) he was
instrumental in improving our website. Provided he accepts the
nomination, I'd like to have him on the boat.

+1 from me.

Jeremias Maerki

RE: (Changing Vote) Re: [VOTE] Andreas L. Delmelle for committer

[Victor Mote]

Andreas L. Delmelle wrote:

> > -Original Message-
> > From: Glen Mazza [mailto:[EMAIL PROTECTED]
> >
> 
> > In particular, his recent handling of a messy
> > disagreement between the committers a couple of weeks
> > back was very helpful
>
> Good to see that it's considered to be helpful. I, myself, was
> not too sure
> at first about whether or not to put it in such strong wordings. Still not
> fully satisfied, though, but if Victor's still monitoring the
> list (closely
> or from a distance), I guess my intention is at least partly fulfilled.

I think you have misunderstood Glen's intent.

Cold turkey would have been better for me, but seemed irresponsible. I have
been monitoring the list to see if Jeremias would respond on the Driver
question. Any future correspondence needing my attention should be directed
to me off-list.

Victor Mote

DO NOT REPLY [Bug 25803] - [PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25803

[PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 12:52 ---
Simon, Your attr_done array is only needed during addAttributesToList(), so I 
think that it should be held in a local vrbl and passed into 
convertAttributeToProperty() and possible into findBaseProperty().

OTOH, I liked your original patch fine, except that I would have called 
getExplicitBaseProp() instead of super.get(), but only because it is a bit more 
descriptive IMHO.

DO NOT REPLY [Bug 25803] - [PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25803

[PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 11:47 ---
Created an attachment (id=9761)
a patch that implements the above suggestion, and a minimal fix for the problem in 
findBaseProperty

DO NOT REPLY [Bug 25828] - [PATCH] fop.sh/bat should use java.endorsed.dirs

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25828

[PATCH] fop.sh/bat should use java.endorsed.dirs





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 11:42 ---
1.) The jar files I propose to put in directory lib/endorsed are also
  added to the classpath. Therefore earlier SDKs will find them as
  usual.

2.) FOP comes with its own jar files for Xerces and Xalan, to ensure
  that a version is used that is adequate for FOP. In SDK 1.4 these
  jar files are not used, because the SDK uses its built-in xerces and
  xalan. My proposed patch makes SDK 1.4 use the Xerces and Xalan jar
  files that come with FOP. As long as it is useful that FOP comes
  with its own xerces and xalan jar files, this patch is useful.

3.) "this" is the patch to fop.sh/bat. "from" is the current
  situation. "to" is a situation in which fop.sh/bat uses the Xerces
  and Xalan jar files that come with FOP when using SDK 1.4.

  The feature I am addressing is that SDK 1.4 on the one hand comes
  with non-core, so-called endorsed standards and implementations, and
  on the other hand allows one to override those by specifying
  "endorsed dirs". All jars in those dirs are prepended to the boot
  class path, and thus prevail over built-in versions of the same
  classes. See guide/standards/index.html in the SDK documentation.

  Xerces and Xalan are probably the best known of these endorsed
  standards, and have caused most problems for users. SDK 1.4.0 came
  with a pretty early version of Xerces 2. It was often necessary to
  override it with versions delivered by applications, using the
  method applied in this patch. The problem may have gone with later
  SDKs.

Re: (PMC'ers) give Finn write access...

[Finn Bock]

[Jeremias Maerki]

Ok, Finn, what we need from you is your preferred unix username and the
email address you would like to have @apache.org forwarded to.
I have always done my open-source work under the 'bckfnn' handle. If 
possible, I would like to pick that as my unixname. Otherwise 'fb' or 
'fbock' will work too.

The forwarding should be done to [EMAIL PROTECTED]

At least as important is to immedidately sign the Contributors License
agreement (CLA) and send (or fax) it to the Apache Software Foundation
as fast as possible. I'd send it in paper, even if it takes longer
there's a higher chance of immediate success. You only get the account
if the CLA has been received. Find the CLA here:
http://www.apache.org/licenses#clas
I've send that yesterday, 30-dec, by snail mail.

As a new committer there are a few things to learn:
http://incubator.apache.org/learn/newcommitters.html
http://incubator.apache.org/learn/
Thank you.

Feel free to ask for help with setting up SSH or whatever when you get
your login.
Thanks. Hopefully I'll manage with the very fine guides.

regards,
finn

DO NOT REPLY [Bug 25806] - [PATCH] fix a NPE in external-graphics.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25806

[PATCH] fix a NPE in external-graphics.





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 10:44 ---
I don't know what I'm doing wrong, but the second attempt at attaching the 
nist.gif still doesn't show the image correctly if I click on the attachment 
link.

I'm able to download the image correctly if I right-click on the attachment 
link and use save-as.

The original image can be found in the zip file:

http://www.w3.org/Style/XSL/XSL-TS-NIST.zip

reference from this page

http://www.w3.org/Style/XSL/TestSuite/

DO NOT REPLY [Bug 25806] - [PATCH] fix a NPE in external-graphics.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25806

[PATCH] fix a NPE in external-graphics.





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 10:40 ---
Created an attachment (id=9760)
Second attempt at attaching nist.gif

DO NOT REPLY [Bug 25803] - [PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25803

[PATCH] PropertyList: Fixes to convertAttributeToProperty and findBaseProperty





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 10:06 ---
I agree with you about the requirements. But the patch does not what you
describe. When the attribute leader-length.maximum is processed, the attribute
leader-length is retrieved from the list of attributes and processed first, out
of order. What I am ignoring is when the attribute is processed again, in the
order of the attributes.

I should add that the patch only works correctly when the issue in item 2 is
also addressed. Without it, the out-of-order processing fails and a default base
property is constructed. This would indeed result in the situation you depict,
with the specification of leader-length being ignored.

A more conservative patch would be to construct a member done in the
propertyList object, which is an array of booleans and keeps track of which
attributes have been processed, so that reprocessing of an attribute is
prevented. The logic of such a solution is more direct and less vulnerable to
logical errrors.

I think that in any solution, the base attribute must be processed before the
compound attribute, as is done now, and that reprocessing of the base attribute
must be prevented. Any method to prevent that is OK.