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 possible to handle both saxon and xalan, because of some incompatible syntax

The main issue about entities generated with latest java in that it breaks man pages.

As pointed out by Lucien, using UTF-8 is a solution that has already been used for the French, and Spanish if I remember correctly.

However, I think that there could still be an issue with man pages generation. With the latest java, it is just garbage, but using UTF-8 in man.en.xsl seems to work.

How-ever I'm not sure that the UTF-8 "trick" would work in all build targets (chm, zip, war, latex which are certainly used by no one but still available). I also don't know if they are broken or still of any use.



Another approach I tried a few months ago was related to:
   <xsl:output method="text" encoding="ISO-8859-1" indent="no" />
(in use actually, and logical based on my understanding of some java docs)

vs

   <xsl:output method="text" encoding="iso8859_1" indent="no" />    (
(found in a slightly different context on https://ant.apache.org/manual/Tasks/style.html, § "Using output properties")

This seems to work for html.en file and also for man pages.


but I didn't get time enough to test it correctly. And Google was not really my friend neither to understand the underlying difference of "ISO-8859-1" vs "iso8859_1", nor what is "the correct one to use".

Testing would mean for me getting the same result with java8 up to java12 (or 13?). Checking that is not that easy on mu Ubuntu VM because older versions of java are no more supported and available. I have to install other VM to test with older version of Ubuntu and java.


Will try to find time in the coming weeks. (no promise)
The only step done in my proposals was axing jakarta. (r1853689 and r1853690)

I also started to test some ant upgrades, but I have the same issues with testing the un-usual targets (chm, zip, war,...)

CJ


Le 08/01/2020 à 02:41, Eric Covener a écrit :
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, external ant, saxon,
old jars removed, and minimal patch to style/ included?  I think this
keeps us out of anyones way just trying to build and check in xforms.

On Sat, Oct 6, 2018 at 3:35 AM Luca Toscano<toscano.l...@gmail.com>  wrote:
Il giorno mar 2 ott 2018 alle ore 15:55 Rainer Jung
<rainer.j...@kippdata.de>  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 leave with the current tool chain
[X] yes. Let clean some dust and update what is needed
What version of XSLT is best for us?
===================================

[ ] 1.0 - this is what I'm used to, keep things stable
[ ] 2.0
[ ] 3.0 - the later the better, and/or the new functionalities rock!
Not qualified to answer.

Should we change our XSLT engine?
================================
[ ] No, I love Xalan and it is ASF. Just move to UTF-8 everywhere.
[X] Yes and Saxon is a good candidate. The license of the Home Edition
      is Mozilla Public License version 2.0.
[ ] Yes and ______ should be used instead
What is the oldest version of Java we should support?
====================================================
[ ] 1.2 - what we claim now
[ ] 1.3 - what is needed required by Xalan 1.7.1
[ ] 1.4
[ ] 5.0 - what is required by Saxon 9.6
[ ] 6 - what is required by Saxon 9.7 and 9.8
[ ] 7
[X] 8 - what is required by the latest Saxon 9.9
[ ] 9
[ ] 10
[ ] 11
Depending of the minimum Java requirement consensus, we could also
wonder if:
     - we still need jakarta-oro Regex parser (ASF, but retired since
2010-09-01). Regex in Java are considered stable since a long time now
       [ ] keep it
       [X] Axe it
If possible.

     - we need to upgrade Ant. (Latest is 1.10.5. Ant 1.9.*: JDK 1.5+,
Ant 1.8.*: JDK 1.4+, Ant 1.7.*: JDK 1.3+, Ant 1.6.*: JDK 1.2+)
       [ ] keep 1.6.5, we don't need to change
       [ ] 1.9.x, recent enough, still maintained, but not the latest.
Should be the more stable
       [ ] 1.10.x, the later the better, and/or the new functionalities
rock!
1.9 or 1.10 would be OK for me.

Regards,

Rainer
+1 to what Rainer said.

Thanks a lot for this work!!

Luca

---------------------------------------------------------------------
To unsubscribe, e-mail:docs-unsubscr...@httpd.apache.org
For additional commands, e-mail:docs-h...@httpd.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org

Reply via email to