Le 30/09/2018 à 17:52, Lucien Gentis a écrit :
Le 29/09/2018 à 15:42, Lucien Gentis a écrit :
Le 29/09/2018 à 09:03, Christophe JAILLET a écrit :
Hi,
There is a bug in the Xalan, the XSLT 1.0 engine we are using, that
prevents our doc building tool chain to generate correct documentation.
On Sat, Sep 29, 2018 at 3:03 AM Christophe JAILLET
wrote:
>
> Hi,
>
> There is a bug in the Xalan, the XSLT 1.0 engine we are using, that
> prevents our doc building tool chain to generate correct documentation.
>
> By not correct, I mean:
> - ISO-8859-1 non ASCII characters are replaced again
Le 20/02/2020 à 23:23, André Malo a écrit :
Rich Bowen wrote:
On 1/9/20 2:14 AM, André Malo wrote:
If you'd ask me, I'd rather kill XML/XSLT entirely, as the promises both
for Java and XML/XSLT clearly don't hold anymore. However this also
requires time and effort...
Revisiting a thread that s
There are also these discussions at
https://lists.apache.org/list.html?docs@httpd.apache.org:2018-9 :
"HTML entities"
and
**
"[VOTE] Update our documentation building tool chain"
I then migrated french doc toward UTF-8 without a problem and could
forget HTML entities.
Found a bug report related to this which was last changed on 2018-08-06:
Bug 57878 - Using UTF-8 for all languages, and avoiding html-entities.
- https://bz.apache.org/bugzilla/show_bug.cgi?id=57878
Mike
On Thu, Feb 20, 2020 at 2:23 PM André Malo wrote:
> Rich Bowen wrote:
> > On 1/9/20 2:14 AM
Rich Bowen wrote:
> On 1/9/20 2:14 AM, André Malo wrote:
> > If you'd ask me, I'd rather kill XML/XSLT entirely, as the promises both
> > for Java and XML/XSLT clearly don't hold anymore. However this also
> > requires time and effort...
>
> Revisiting a thread that somewhat died out ... I would a
I vote up for any upgrade.
El jue., 20 feb. 2020 19:28, Tim Bannister
escribió:
> The cloud native computing foundation (especially Kubernetes) is largely
> using Hugo and it seems to work well.
>
> Tim
>
> On 20 February 2020 18:16:11 Rich Bowen wrote:
>
> > On 1/9/20 2:14 AM, André Malo wrot
The cloud native computing foundation (especially Kubernetes) is largely
using Hugo and it seems to work well.
Tim
On 20 February 2020 18:16:11 Rich Bowen wrote:
On 1/9/20 2:14 AM, André Malo wrote:
If you'd ask me, I'd rather kill XML/XSLT entirely, as the promises both for
Java and XML/XS
On 1/9/20 2:14 AM, André Malo wrote:
If you'd ask me, I'd rather kill XML/XSLT entirely, as the promises both for
Java and XML/XSLT clearly don't hold anymore. However this also requires
time and effort...
Revisiting a thread that somewhat died out ... I would also be very much
in favor of
On Mittwoch, 8. Januar 2020 22:33:19 CET Christophe JAILLET wrote:
> Hi Eric,
>
> I was just about to remind @dev about this known issue.
>
> Yes, interested to dig further, but honestly, I lack time since several
> months.
> If I recollect correctly:
> - there is still some corner issues wit
Hi Eric,
I was just about to remind @dev about this known issue.
Yes, interested to dig further, but honestly, I lack time since several
months.
If I recollect correctly:
- there is still some corner issues with saxon. (and a few patches
already in trunk, waiting for 2.4.x)
- it is not
Digging around in docs-build via Mikes recent thread reminded me of all this.
Christophe, any interest/cycles to revisit? It might be nice to move
up before this analysis ages too much.
My thought to proceed after reviewing the thread: Should we
collaborate on a new docs-build w/ java8 min, ext
Il giorno mar 2 ott 2018 alle ore 15:55 Rainer Jung
ha scritto:
>
> Am 29.09.2018 um 09:03 schrieb Christophe JAILLET:
> > Do we need to change something?
> > ==
> > [ ] this mail is too long, do whatever you want, I just want something
> > that works
> > [ ] no. I can
On 10/02/2018 05:08 PM, Joe Orton wrote:
> On Sat, Sep 29, 2018 at 09:03:46AM +0200, Christophe JAILLET wrote:
>> Do we need to change something?
>> ==
>> [X] this mail is too long, do whatever you want, I just want something that
>> works
>> [ ] no. I can leave with
On Tue, Oct 2, 2018 at 5:21 AM Tom Fredrik Blenning wrote:
>
> On 02/10/2018 02:28, William A Rowe Jr wrote:
> >
> > Very concerned about trusting utf-8 for anything that is expected to be
> > console
> > readable. Not as much the xml/html decorated contents, but the man pages
> > and any text fi
On Sat, Sep 29, 2018 at 09:03:46AM +0200, Christophe JAILLET wrote:
> Do we need to change something?
> ==
> [X] this mail is too long, do whatever you want, I just want something that
> works
> [ ] no. I can leave with the current tool chain
> [X] yes. Let clean some du
I, for one, would love to see us move to something MarkDown based.
However, 1) that would be a HUGE amount of work and 2) it would take a
lot more work to make something MD-based support all of the fancy
features that we have hacked into our existing engine over the years.
However, I must also
Am 29.09.2018 um 09:03 schrieb Christophe JAILLET:
Do we need to change something?
==
[ ] this mail is too long, do whatever you want, I just want something
that works
[ ] no. I can leave with the current tool chain
[X] yes. Let clean some dust and update what is nee
On 02/10/2018 02:28, William A Rowe Jr wrote:
> On Mon, Oct 1, 2018 at 4:15 PM Luis Gil de Bernabé
> wrote:
>
>> I have updated long ago the files from es, but i wasn't sure to commit
>> them as the FR file Lucien is saying.
>> So now i'm sure it could be done, i will add them to trunk (es
>> m
Le 02/10/2018 à 08:57, André Malo a écrit :
On Montag, 1. Oktober 2018 23:14:58 CEST Luis Gil de Bernabé wrote:
I have updated long ago the files from es, but i wasn't sure to commit
them as the FR file Lucien is saying.
So now i'm sure it could be done, i will add them to trunk (es
modificat
On Montag, 1. Oktober 2018 23:14:58 CEST Luis Gil de Bernabé wrote:
> I have updated long ago the files from es, but i wasn't sure to commit
> them as the FR file Lucien is saying.
> So now i'm sure it could be done, i will add them to trunk (es
> modification only)
Side note here. All UTF-8 targe
On Mon, Oct 1, 2018 at 4:15 PM Luis Gil de Bernabé
wrote:
> I have updated long ago the files from es, but i wasn't sure to commit
> them as the FR file Lucien is saying.
> So now i'm sure it could be done, i will add them to trunk (es
> modification only)
>
> @Christophe JAILLET im not helpful
I have updated long ago the files from es, but i wasn't sure to commit
them as the FR file Lucien is saying.
So now i'm sure it could be done, i will add them to trunk (es modification
only)
@Christophe JAILLET im not helpfull here,
but i vote +1 to update our build tool :)
rgd
On Mon, 1 Oct 20
Le 29/09/2018 à 15:27, Eric Covener a écrit :
As per Xalan documentation, the JDK or JRE 1.3.x (2000), 1.4.x (2002),
or 5.x (2004) is required.
As per our doc build documentation, we need at least Java 1.2 (1998) to
build the doc.
Java 8 (2014) is LTS and is supported until 2025
Java 9 (2017)
Jav
Le 29/09/2018 à 15:42, Lucien Gentis a écrit :
Le 29/09/2018 à 09:03, Christophe JAILLET a écrit :
Hi,
There is a bug in the Xalan, the XSLT 1.0 engine we are using, that
prevents our doc building tool chain to generate correct documentation.
By not correct, I mean:
- ISO-8859-1 non
Le 29/09/2018 à 09:03, Christophe JAILLET a écrit :
Hi,
There is a bug in the Xalan, the XSLT 1.0 engine we are using, that
prevents our doc building tool chain to generate correct documentation.
By not correct, I mean:
- ISO-8859-1 non ASCII characters are replaced again by their HTML
> As per Xalan documentation, the JDK or JRE 1.3.x (2000), 1.4.x (2002),
> or 5.x (2004) is required.
> As per our doc build documentation, we need at least Java 1.2 (1998) to
> build the doc.
> Java 8 (2014) is LTS and is supported until 2025
> Java 9 (2017)
> Java 10 (2018)
> Java 11 (2018) is ap
Le 29/09/2018 à 09:03, Christophe JAILLET a écrit :
Hi,
There is a bug in the Xalan, the XSLT 1.0 engine we are using, that
prevents our doc building tool chain to generate correct documentation.
By not correct, I mean:
- ISO-8859-1 non ASCII characters are replaced again by their HTML
en
Hi,
There is a bug in the Xalan, the XSLT 1.0 engine we are using, that
prevents our doc building tool chain to generate correct documentation.
By not correct, I mean:
- ISO-8859-1 non ASCII characters are replaced again by their HTML
entities equivalent (in the French doc for example)
29 matches
Mail list logo