DO NOT REPLY [Bug 17311] New: - Manifest file class path contains outdated entries

[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=17311

Manifest file class path contains outdated entries

   Summary: Manifest file class path contains outdated entries
   Product: Fop
   Version: 0.20.5
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The class path set in the manifest file of the fop.jar in both 20.5rc releases 
contains outdated entries for the xalan and xercesImpl JAR's.




That makes this releases unusable for applications which use FOP's embedding 
mechanism and rely on FOP to set it's class path properly.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Licence issues in hyphenation patterns

[Dirk-Willem van Gulik]

On Sat, 22 Feb 2003, Peter B. West wrote:

> As long as we are still able to recover complete historical binary
> distributions.  If a problem arises over a past distribution, we are far
> better off if we can refer to the actual distribution, even if that is
> no longer available for general distribution.

If you are worried about such things - you can -always- ask the secretary
of the board@ (Jim Jagielski) to put something on file. On paper, or
digital - with a date and to be kept for prosetiry. I.e. as an
incorperated foundation we have the framework for such things.

Dw


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Long licence

[Arved Sandstrom]

> -Original Message-
> From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]
> Sent: February 21, 2003 1:35 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Long licence
>
> On Fri, 21 Feb 2003, Arved Sandstrom wrote:
>
> > I'd like to find out what lawyer thought a long license is
> needed with every
> > file. Because I question that finding.
>
> Question the board@ (again) for a black/white answer - or work with
> licensing@ for a more interactive reply.

Point taken. I get too much email already, so I've been averse to joining
more lists. Maybe in this case I should join another.

> But Bear in mind that the current 'license' is more than just strictly a
> license; it contains elements of copyright, waiver and an agreement.

Understood.

> Bear in mind that the answer to vague questions like that carry very
> significant price tags; and are very depended on the exact question; which
> itself by its very nature is inexact.

Yes. It's our business to pose the exact questions. It's the business of the
lawyer to supply an answer.

FWIW, I am not vilifying lawyers. My older sister is one. :-)

I feel like the right questions weren't asked.

> Also bear in mind that there are very, very few layers who actually have
> studied open-source licenses in sufficient dept; and that most answers
> from case-law are about proprietary and protectionist stances; and often
> very US specific; and may be very dated.

Yes, I agree.

> Also bear in mind that the answer differs from jurisdiction to
> jurisdiction; and from how litagationous/defensive the side you want to
> err on is.

Well, I differ from our US friends on this. I prefer to be terse and clear,
and maintain some trust in people.

> Finally bear in mind that the board propably does not want to ask
> expensive questions now with respect to the current license; as the new
> license is not far off - and the new license has taken into account this
> desire to include by reference.

OK, fair enough. I'll wait to see it.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: XMLReader...

[J.Pietschmann]

Swapan Golla wrote:
[ERROR] Could not load external SVG: SAX2 driver class
weblogic.xml.jaxp.RegistryXMLReader loaded but cannot
be instantiated
 (no empty public constructor?)
This is something you should complain to your WebLogic
support.
Is there a way I can instruct the SVG transcoder API
to use a specific xmlreader than the one used by
weblogic ? 
It depends. The easiest way would be to put the jar
with the parser you want to use in the classpath before
the WebLogic jar. If you use JDK 1.4 , you can copy the
jar to the JDK's lib/endorsed directory. Another possiblity
is to set the java.xml.parsers.SAXParserFactory service
to the class name of the factory you want to use.
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Arved Sandstrom]

Well, Peter, no, I haven't written something this direct - yet. My trust in
their responsiveness is at an ebb; they don't answer much communication, of
any nature, quickly, so I doubt that they will answer a more critical email
at all.

FWIW I consider all of the editors to be way more experienced than me, when
it comes to documents, and publishing, and so forth. I don't equate that
with expertise in math, or programming, or technical writing. Number one,
trained technical writers should write technical docs - a whole bunch of W3C
recommendations prove that. _I_ am not very good at writing technical docs;
I get windy and abstruse. That's why I don't get paid to write docs. :-)

Every XSL-FO implementation has a different treatment of
"reference-orientation". I keep harping on this, I know. In fact, I think
_my_ interpretation is correct, and almost everyone else is wrong. I think
that because I read the English in the spec. I know that sounds arrogant,
but I have told the editors before that I'll implement according to the
letter, not the spirit. If they wish to argue that the language says
differently than what I think, that's their prerogative.

There is a better procedure for turning out specs. The W3C hasn't twigged.
Good companies in the industry already know it. It's invite the
customers/clients in, get them to hash things out with the programmers and
technical writers, and then let the latter two groups turn out a good
document, or a good implementation. Or both. In this case the experts are
the customers; we have a confused spec because they thought they were the
programmers and writers as well.

Arved

> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
> Sent: February 22, 2003 8:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Markers in areas
>
>
> Arved Sandstrom wrote:
> > They are not connected concepts, Mark. I originally put in the code for
> > lineage pairs, and also started the implementation for markers. So I can
> > assure you that they are completely unrelated. For what it's worth,
> > subsequent contributors have significantly improved on marker
> support, so I
> > am only commenting from the viewpoint of my knowledge of the spec.
> >
> > I made a few comments in my reply to Joerg. I have a degree in
> physics, and
> > most of a Masters in physical oceanography. I see considerable
> mathematical
> > anarchy in the XSL spec, some degree of mathematical naivete,
> and lots of
> > confusion. My forte is not logic, based on my background, but
> even a physics
> > guy can dissect the pseudo-logic in that spec. I think plenty of other
> > people have also separated the wheat from the chaff as far as
> that document
> > is concerned...I think we are due for a rewrite, with lots of the
> > pretentious math excised, and replaced with plain language.
>
> Arved,
>
> Hear, hear.  Arved, have you told the editors this directly?  If not,
> please do.
>
> --
> Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
> "Lord, to whom shall we go?"
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Markers in areas

[Peter B. West]

Arved Sandstrom wrote:
They are not connected concepts, Mark. I originally put in the code for
lineage pairs, and also started the implementation for markers. So I can
assure you that they are completely unrelated. For what it's worth,
subsequent contributors have significantly improved on marker support, so I
am only commenting from the viewpoint of my knowledge of the spec.
I made a few comments in my reply to Joerg. I have a degree in physics, and
most of a Masters in physical oceanography. I see considerable mathematical
anarchy in the XSL spec, some degree of mathematical naivete, and lots of
confusion. My forte is not logic, based on my background, but even a physics
guy can dissect the pseudo-logic in that spec. I think plenty of other
people have also separated the wheat from the chaff as far as that document
is concerned...I think we are due for a rewrite, with lots of the
pretentious math excised, and replaced with plain language.
Arved,

Hear, hear.  Arved, have you told the editors this directly?  If not, 
please do.

--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Markers in areas

[Peter B. West]

Arved Sandstrom wrote:
Joerg, you can freely get rid of that stuff. I originally introduced it when
I had more faith in the spec, and thought that the authors knew what they
were talking about when it came to to their math. Specifically, the lineage
pairs is an abstract concept that I can see no implementation use for. In
fact, I can't see any theoretical use for the idea either.
Arved,

I'm glad that I am not the only one who could see no purpose in the 
discussion of "lineage".  However, I'd like your comments on a couple of 
aspects of lineage.

The first of the two parts of the definition:

A set of nodes in a tree is a lineage if:
*  there is a node N in the set such that all the nodes in the set 
are ancestors of N, and


This seems a strange.

Normal areas represent areas in the "normal flow of text"; that 
is, they become area children of the areas generated by the formatting 
object to which they are returned. Normal areas have a returned-by 
lineage of size one.

I wondered about the point of all this, but in looking at the Errata, I 
found a series of modifications for the description of 'Areas' in the 
description of fo:bidi-override, fo:inline and fo:basic-link as follows:

Section 6.6.2

Replace:

in the "Areas:" portion "returns these areas, any page-level-out-of-line 
areas, and any reference-level-out-of-line areas returned by the children"

with

"returns these areas, together with any normal block-areas, 
page-level-out-of-line areas, and reference-level-out-of-line areas 
returned by the children"

It seesm to me that these changes create normal block areas with a 
lineage with size greater than one.

What do you think?

--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]