You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by sp...@apache.org on 2009/08/18 22:05:01 UTC
svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./
src/java/org/apache/fop/hyphenation/ src/java/org/apache/fop/tools/anttasks/
Author: spepping
Date: Tue Aug 18 20:05:01 2009
New Revision: 805561
URL: http://svn.apache.org/viewvc?rev=805561&view=rev
Log:
Prepare for new hyphenation pattern files, which do not have their own classes and instead use the default classes in FOP. Modified the build process to a forked java task, in order to be able to set a larger stack size for the compilation of the large number of classes. Added an ant task to generate a new default classes file, to be used with an update of the Unicode Character Database.
Added:
xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java (with props)
xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java (with props)
xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/classes.xml (with props)
Removed:
xmlgraphics/fop/trunk/src/java/org/apache/fop/tools/anttasks/SerializeHyphPattern.java
Modified:
xmlgraphics/fop/trunk/build.properties
xmlgraphics/fop/trunk/build.xml
xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java
Modified: xmlgraphics/fop/trunk/build.properties
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/build.properties?rev=805561&r1=805560&r2=805561&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/build.properties (original)
+++ xmlgraphics/fop/trunk/build.properties Tue Aug 18 20:05:01 2009
@@ -50,5 +50,6 @@
# layoutengine.disabled = test/layoutengine/disabled-testcases.txt
## Specify an alternate directory to scan for user supplied
-## hyphenation pattern files.
+## hyphenation pattern files and Unicode data files.
# user.hyph.dir = /home/bart/offo
+# unidata.dir = /usr/share/doc/Unicode/UNIDATA
Modified: xmlgraphics/fop/trunk/build.xml
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/build.xml?rev=805561&r1=805560&r2=805561&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/build.xml (original)
+++ xmlgraphics/fop/trunk/build.xml Tue Aug 18 20:05:01 2009
@@ -157,6 +157,8 @@
<property name="fo.examples.force" value="false"/>
<property name="lib.dir" value="${basedir}/lib"/>
<property name="user.hyph.dir" value="${basedir}/hyph"/>
+ <property name="unidata.dir" value="${basedir}/UNIDATA"/>
+ <property name="hyph.stacksize" value="512k"/>
<property name="build.dir" value="${basedir}/build"/>
<property name="build.gensrc.dir" value="${build.dir}/gensrc"/>
<property name="build.classes.dir" value="${build.dir}/classes"/>
@@ -425,21 +427,51 @@
</copy>
</target>
<target name="compile" depends="compile-java, compile-copy-resources" description="Compiles the source code"/>
-<!-- =================================================================== -->
-<!-- compiles hyphenation patterns -->
-<!-- =================================================================== -->
- <target name="compile-hyphenation" depends="compile">
+ <!-- =================================================================== -->
+ <!-- Helper task to generate source files that have already been checked -->
+ <!-- into the repository. This task uses Unicode Character Database -->
+ <!-- files. This task need only be run when the latter files have been -->
+ <!-- updated. This target should never be part of the normal build -->
+ <!-- process. Output is UnicodeClasses.CLASSES_XML -->
+ <!-- (src/java/org/apache/fop/hyphenation/classes.xml). -->
+ <!-- =================================================================== -->
+ <target name="codegen-hyphenation-classes">
+ <java classname="org.apache.fop.hyphenation.UnicodeClasses" resultproperty="classes.result" classpath="${build.classes.dir}">
+ <arg value="${unidata.dir}"/>
+ </java>
+ <condition property="classes.result.message" value="Generation of classes successful">
+ <not>
+ <isfailure code="${classes.result}"/>
+ </not>
+ </condition>
+ <condition property="classes.result.message" value="Generation of classes failed">
+ <isfailure code="${classes.result}"/>
+ </condition>
+ <echo message="${classes.result.message}"/>
+ </target>
+ <!-- =================================================================== -->
+ <!-- compiles hyphenation patterns -->
+ <!-- =================================================================== -->
+ <target name="compile-hyphenation" depends="compile" description="Compiles the hyphenation pattern files">
<path id="hyph-classpath">
<path refid="libs-build-classpath"/>
<pathelement location="${build.classes.dir}"/>
</path>
- <taskdef name="serHyph" classname="org.apache.fop.tools.anttasks.SerializeHyphPattern" classpathref="hyph-classpath"/>
<mkdir dir="${build.classes.dir}/hyph"/>
- <serHyph targetDir="${build.classes.dir}/hyph">
- <fileset dir="${user.hyph.dir}">
- <include name="*.xml"/>
- </fileset>
- </serHyph>
+ <java classname="org.apache.fop.hyphenation.SerializeHyphPattern" fork="true" resultproperty="hyph.result" classpathref="hyph-classpath">
+ <arg value="${user.hyph.dir}"/>
+ <arg value="${build.classes.dir}/hyph"/>
+ <jvmarg value="-Xss${hyph.stacksize}"/>
+ </java>
+ <condition property="hyph.result.message" value="Hyphenation successful">
+ <not>
+ <isfailure code="${hyph.result}"/>
+ </not>
+ </condition>
+ <condition property="hyph.result.message" value="Hyphenation failed">
+ <isfailure code="${hyph.result}"/>
+ </condition>
+ <echo message="${hyph.result.message}"/>
</target>
<target name="uptodate-jar-hyphenation" depends="compile-hyphenation">
<uptodate property="jar.hyphenation.uptodate" targetfile="${build.dir}/fop-hyph.jar">
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java?rev=805561&r1=805560&r2=805561&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java Tue Aug 18 20:05:01 2009
@@ -30,7 +30,10 @@
// Java
import java.io.File;
import java.io.FileNotFoundException;
+import java.io.FileOutputStream;
import java.io.IOException;
+import java.io.InputStream;
+import java.io.PrintStream;
import java.net.MalformedURLException;
import java.util.ArrayList;
@@ -51,6 +54,7 @@
ArrayList exception;
char hyphenChar;
String errMsg;
+ boolean hasClasses = false;
static final int ELEM_CLASSES = 1;
static final int ELEM_EXCEPTIONS = 2;
@@ -58,24 +62,19 @@
static final int ELEM_HYPHEN = 4;
public PatternParser() throws HyphenationException {
+ this.consumer = this;
token = new StringBuffer();
parser = createParser();
parser.setContentHandler(this);
parser.setErrorHandler(this);
hyphenChar = '-'; // default
-
}
- public PatternParser(PatternConsumer consumer)
- throws HyphenationException {
+ public PatternParser(PatternConsumer consumer) throws HyphenationException {
this();
this.consumer = consumer;
}
- public void setConsumer(PatternConsumer consumer) {
- this.consumer = consumer;
- }
-
/**
* Parses a hyphenation pattern file.
* @param filename the filename
@@ -249,15 +248,32 @@
return il.toString();
}
+ protected void getExternalClasses() throws SAXException {
+ XMLReader mainParser = parser;
+ parser = createParser();
+ parser.setContentHandler(this);
+ parser.setErrorHandler(this);
+ InputStream stream = this.getClass().getResourceAsStream("classes.xml");
+ InputSource source = new InputSource(stream);
+ try {
+ parser.parse(source);
+ } catch (IOException ioe) {
+ throw new SAXException(ioe.getMessage());
+ } finally {
+ parser = mainParser;
+ }
+ }
+
//
// ContentHandler methods
//
/**
* {@inheritDoc}
+ * @throws SAXException
*/
public void startElement(String uri, String local, String raw,
- Attributes attrs) {
+ Attributes attrs) throws SAXException {
if (local.equals("hyphen-char")) {
String h = attrs.getValue("value");
if (h != null && h.length() == 1) {
@@ -266,8 +282,14 @@
} else if (local.equals("classes")) {
currElement = ELEM_CLASSES;
} else if (local.equals("patterns")) {
+ if (!hasClasses) {
+ getExternalClasses();
+ }
currElement = ELEM_PATTERNS;
} else if (local.equals("exceptions")) {
+ if (!hasClasses) {
+ getExternalClasses();
+ }
currElement = ELEM_EXCEPTIONS;
exception = new ArrayList();
} else if (local.equals("hyphen")) {
@@ -311,6 +333,9 @@
token.setLength(0);
}
}
+ if (currElement == ELEM_CLASSES) {
+ hasClasses = true;
+ }
if (currElement == ELEM_HYPHEN) {
currElement = ELEM_EXCEPTIONS;
} else {
@@ -403,23 +428,46 @@
// PatternConsumer implementation for testing purposes
public void addClass(String c) {
- System.out.println("class: " + c);
+ testOut.println("class: " + c);
}
public void addException(String w, ArrayList e) {
- System.out.println("exception: " + w + " : " + e.toString());
+ testOut.println("exception: " + w + " : " + e.toString());
}
public void addPattern(String p, String v) {
- System.out.println("pattern: " + p + " : " + v);
+ testOut.println("pattern: " + p + " : " + v);
+ }
+
+ private PrintStream testOut = System.out;
+
+ /**
+ * @param testOut the testOut to set
+ */
+ public void setTestOut(PrintStream testOut) {
+ this.testOut = testOut;
+ }
+
+ public void closeTestOut() {
+ testOut.flush();
+ testOut.close();
}
public static void main(String[] args) throws Exception {
if (args.length > 0) {
PatternParser pp = new PatternParser();
- pp.setConsumer(pp);
+ PrintStream p = null;
+ if (args.length > 1) {
+ FileOutputStream f = new FileOutputStream(args[1]);
+ p = new PrintStream(f, false, "utf-8");
+ pp.setTestOut(p);
+ }
pp.parse(args[0]);
+ if (pp != null) {
+ pp.closeTestOut();
+ }
}
}
+
}
Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java?rev=805561&view=auto
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java (added)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java Tue Aug 18 20:05:01 2009
@@ -0,0 +1,132 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* $Id$ */
+
+package org.apache.fop.hyphenation;
+
+import java.io.File;
+import java.io.FilenameFilter;
+import java.io.IOException;
+import java.io.ObjectOutputStream;
+
+/**
+ * Serialize hyphenation patterns
+ * For all xml files in the source directory a pattern file is built in the target directory
+ * This class may be called from the ant build file in a java task
+ */
+public class SerializeHyphPattern {
+
+ private boolean errorDump = false;
+
+ /**
+ * Controls the amount of error information dumped.
+ * @param errorDump True if more error info should be provided
+ */
+ public void setErrorDump(boolean errorDump) {
+ this.errorDump = errorDump;
+ }
+
+ /**
+ * {@inheritDoc}
+ */
+ public void serializeDir(File sourceDir, File targetDir) {
+ final String extension = ".xml";
+ String[] sourceFiles = sourceDir.list(new FilenameFilter() {
+ public boolean accept(File dir, String name) {
+ return(name.endsWith(extension));
+ }
+ });
+ for (int j = 0; j < sourceFiles.length; j++) {
+ File infile = new File(sourceDir, sourceFiles[j]);
+ String outfilename =
+ sourceFiles[j].substring(0, sourceFiles[j].length() - extension.length()) + ".hyp";
+ File outfile = new File(targetDir, outfilename);
+ serializeFile(infile, outfile);
+ }
+ }
+
+ /*
+ * checks whether input or output files exists or the latter is older than input file
+ * and start build if necessary
+ */
+ private void serializeFile(File infile, File outfile) {
+ boolean startProcess;
+ startProcess = rebuild(infile, outfile);
+ if (startProcess) {
+ HyphenationTree hTree = buildPatternFile(infile);
+ // serialize class
+ try {
+ ObjectOutputStream out = new ObjectOutputStream(
+ new java.io.BufferedOutputStream(
+ new java.io.FileOutputStream(outfile)));
+ out.writeObject(hTree);
+ out.close();
+ } catch (IOException ioe) {
+ System.err.println("Can't write compiled pattern file: "
+ + outfile);
+ System.err.println(ioe);
+ }
+ }
+ }
+
+ /*
+ * serializes pattern files
+ */
+ private HyphenationTree buildPatternFile(File infile) {
+ System.out.println("Processing " + infile);
+ HyphenationTree hTree = new HyphenationTree();
+ try {
+ hTree.loadPatterns(infile.toString());
+ if (errorDump) {
+ System.out.println("Stats: ");
+ hTree.printStats();
+ }
+ } catch (HyphenationException ex) {
+ System.err.println("Can't load patterns from xml file " + infile
+ + " - Maybe hyphenation.dtd is missing?");
+ if (errorDump) {
+ System.err.println(ex.toString());
+ }
+ }
+ return hTree;
+ }
+
+ /**
+ * Checks for existence of output file and compares
+ * dates with input and stylesheet file
+ */
+ private boolean rebuild(File infile, File outfile) {
+ if (outfile.exists()) {
+ // checks whether output file is older than input file
+ if (outfile.lastModified() < infile.lastModified()) {
+ return true;
+ }
+ } else {
+ // if output file does not exist, start process
+ return true;
+ }
+ return false;
+ } // end rebuild
+
+
+ public static void main (String args[]) {
+ SerializeHyphPattern ser = new SerializeHyphPattern();
+ ser.serializeDir(new File(args[0]), new File(args[1]));
+ }
+
+}
Propchange: xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java
------------------------------------------------------------------------------
svn:keywords = Id
Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java?rev=805561&view=auto
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java (added)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java Tue Aug 18 20:05:01 2009
@@ -0,0 +1,317 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* $Id$ */
+
+package org.apache.fop.hyphenation;
+
+import java.io.BufferedReader;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.InputStreamReader;
+import java.io.OutputStreamWriter;
+import java.util.HashMap;
+import java.util.Map;
+
+/**
+ * Create the default classes file classes.xml,
+ * for use in building hyphenation patterns
+ * from pattern files which do not contain their own classes
+ */
+public class UnicodeClasses {
+
+ // default path relative to the FOP base directory
+ static String CLASSES_XML = "src/java/org/apache/fop/hyphenation/classes.xml";
+
+ /**
+ * Generate classes.xml from Java's compiled-in Unicode Character Database
+ * @param hexcode whether to prefix each class with the hexcode (only for debugging purposes)
+ * @param outfilePath output file
+ * @throws IOException
+ */
+ public static void fromJava(boolean hexcode, String outfilePath) throws IOException {
+ File f = new File(outfilePath);
+ if (f.exists()) {
+ f.delete();
+ }
+ f.createNewFile();
+ FileOutputStream fw = new FileOutputStream(f);
+ OutputStreamWriter ow = new OutputStreamWriter(fw, "utf-8");
+ int maxChar;
+ maxChar = Character.MAX_VALUE;
+
+ ow.write("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n" +
+ "<classes>\n");
+ // loop over the first Unicode plane
+ for (int code = Character.MIN_VALUE; code <= maxChar; ++code) {
+
+ // skip surrogate area
+ if (code == Character.MIN_SURROGATE) {
+ code = Character.MAX_SURROGATE;
+ continue;
+ }
+
+ // we are only interested in LC, UC and TC letters which are their own LC, and in 'other letters'
+ if (!(((Character.isLowerCase(code) || Character.isUpperCase(code) || Character.isTitleCase(code))
+ && code == Character.toLowerCase(code))
+ || Character.getType(code) == Character.OTHER_LETTER)) {
+ continue;
+ }
+
+ // skip a number of blocks
+ Character.UnicodeBlock ubi = Character.UnicodeBlock.of(code);
+ if (ubi.equals(Character.UnicodeBlock.SUPERSCRIPTS_AND_SUBSCRIPTS)
+ || ubi.equals(Character.UnicodeBlock.LETTERLIKE_SYMBOLS)
+ || ubi.equals(Character.UnicodeBlock.ALPHABETIC_PRESENTATION_FORMS)
+ || ubi.equals(Character.UnicodeBlock.HALFWIDTH_AND_FULLWIDTH_FORMS)
+ || ubi.equals(Character.UnicodeBlock.CJK_UNIFIED_IDEOGRAPHS)
+ || ubi.equals(Character.UnicodeBlock.CJK_UNIFIED_IDEOGRAPHS_EXTENSION_A)
+ || ubi.equals(Character.UnicodeBlock.HANGUL_SYLLABLES)) {
+ continue;
+ }
+
+ int uppercode = Character.toUpperCase(code);
+ int titlecode = Character.toTitleCase(code);
+ StringBuilder s = new StringBuilder();
+ if (hexcode) {
+ s.append("0x" + Integer.toHexString(code) + " ");
+ }
+ s.append(Character.toChars(code));
+ if (uppercode != code) {
+ s.append(Character.toChars(uppercode));
+ }
+ if (titlecode != code && titlecode != uppercode) {
+ s.append(Character.toChars(titlecode));
+ }
+ ow.write(s.toString() + "\n");
+ }
+ ow.write("</classes>\n");
+ ow.flush();
+ ow.close();
+ }
+
+ static public int UNICODE = 0, GENERAL_CATEGORY = 2, SIMPLE_UPPERCASE_MAPPING = 12,
+ SIMPLE_LOWERCASE_MAPPING = 13, SIMPLE_TITLECASE_MAPPING = 14, NUM_FIELDS = 15;
+
+ /**
+ * Generate classes.xml from Unicode Character Database files
+ * @param hexcode whether to prefix each class with the hexcode (only for debugging purposes)
+ * @param unidataPath path to the directory with UCD files
+ * @param outfilePath output file
+ * @throws IOException
+ */
+ public static void fromUCD(boolean hexcode, String unidataPath, String outfilePath) throws IOException {
+ File unidata = new File(unidataPath);
+
+ File f = new File(outfilePath);
+ if (f.exists()) {
+ f.delete();
+ }
+ f.createNewFile();
+ FileOutputStream fw = new FileOutputStream(f);
+ OutputStreamWriter ow = new OutputStreamWriter(fw, "utf-8");
+
+ File in = new File(unidata, "Blocks.txt");
+ FileInputStream inis = new FileInputStream(in);
+ InputStreamReader insr = new InputStreamReader(inis, "utf-8");
+ BufferedReader inbr = new BufferedReader(insr);
+ Map blocks = new HashMap();
+ for (String line = inbr.readLine(); line != null; line = inbr.readLine()) {
+ if (line.startsWith("#") || line.matches("^\\s*$")) {
+ continue;
+ }
+ String[] parts = line.split(";");
+ String block = parts[1].trim();
+ String[] indices = parts[0].split("\\.\\.");
+ int[] ind = {Integer.parseInt(indices[0], 16), Integer.parseInt(indices[1], 16)};
+ blocks.put(block, ind);
+ }
+ inbr.close();
+
+ in = new File(unidata, "UnicodeData.txt");
+ inis = new FileInputStream(in);
+ insr = new InputStreamReader(inis, "utf-8");
+ inbr = new BufferedReader(insr);
+ int maxChar;
+ maxChar = Character.MAX_VALUE;
+
+ ow.write("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n" +
+ "<classes>\n");
+ for (String line = inbr.readLine(); line != null; line = inbr.readLine()) {
+ String[] fields = line.split(";", NUM_FIELDS);
+ int code = Integer.parseInt(fields[UNICODE], 16);
+ if (code > maxChar) {
+ break;
+ }
+ if (((fields[GENERAL_CATEGORY].equals("Ll") || fields[GENERAL_CATEGORY].equals("Lu")
+ || fields[GENERAL_CATEGORY].equals("Lt"))
+ && ("".equals(fields[SIMPLE_LOWERCASE_MAPPING])
+ || fields[UNICODE].equals(fields[SIMPLE_LOWERCASE_MAPPING])))
+ || fields[GENERAL_CATEGORY].equals("Lo")) {
+ String[] blockNames = {"Superscripts and Subscripts", "Letterlike Symbols",
+ "Alphabetic Presentation Forms", "Halfwidth and Fullwidth Forms",
+ "CJK Unified Ideographs", "CJK Unified Ideographs Extension A",
+ "Hangul Syllables"};
+ int j;
+ for (j = 0; j < blockNames.length; ++j) {
+ int[] ind = (int[]) blocks.get(blockNames[j]);
+ if (code >= ind[0] && code <= ind[1]) {
+ break;
+ }
+ }
+ if (j < blockNames.length) {
+ continue;
+ }
+
+ int uppercode = -1, titlecode = -1;
+ if (!"".equals(fields[SIMPLE_UPPERCASE_MAPPING])) {
+ uppercode = Integer.parseInt(fields[SIMPLE_UPPERCASE_MAPPING], 16);
+ }
+ if (!"".equals(fields[SIMPLE_TITLECASE_MAPPING])) {
+ titlecode = Integer.parseInt(fields[SIMPLE_TITLECASE_MAPPING], 16);
+ }
+ StringBuilder s = new StringBuilder();
+ if (hexcode) {
+ s.append("0x" + fields[UNICODE].replaceFirst("^0+", "").toLowerCase() + " ");
+ }
+ s.append(Character.toChars(code));
+ if (uppercode != -1 && uppercode != code) {
+ s.append(Character.toChars(uppercode));
+ }
+ if (titlecode != -1 && titlecode != code && titlecode != uppercode) {
+ s.append(Character.toChars(titlecode));
+ }
+ ow.write(s.toString() + "\n");
+ }
+ }
+ ow.write("</classes>\n");
+ ow.flush();
+ ow.close();
+ inbr.close();
+ }
+
+ /**
+ * Generate classes.xml from XeTeX's Unicode letters file
+ * @param hexcode whether to prefix each class with the hexcode (only for debugging purposes)
+ * @param lettersPath path to XeTeX's Unicode letters file unicode-letters-XeTeX.tex
+ * @param outfilePath output file
+ * @throws IOException
+ */
+ public static void fromTeX(boolean hexcode, String lettersPath, String outfilePath) throws IOException {
+ File in = new File(lettersPath);
+
+ File f = new File(outfilePath);
+ if (f.exists()) {
+ f.delete();
+ }
+ f.createNewFile();
+ FileOutputStream fw = new FileOutputStream(f);
+ OutputStreamWriter ow = new OutputStreamWriter(fw, "utf-8");
+
+ FileInputStream inis = new FileInputStream(in);
+ InputStreamReader insr = new InputStreamReader(inis, "utf-8");
+ BufferedReader inbr = new BufferedReader(insr);
+
+ ow.write("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n" +
+ "<classes>\n");
+ for (String line = inbr.readLine(); line != null; line = inbr.readLine()) {
+ String[] codes = line.split("\\s+");
+ if (!(codes[0].equals("\\L") || codes[0].equals("\\l"))) {
+ continue;
+ }
+ if (codes.length == 3) {
+ ow.write("\"" + line + "\" has two codes");
+ continue;
+ }
+ if (codes[0].equals("\\l") && codes.length != 2) {
+ ow.write("\"" + line + "\" should have one code");
+ continue;
+ }
+ else if (codes[0].equals("\\L") && codes.length != 4) {
+ ow.write("\"" + line + "\" should have three codes");
+ continue;
+ }
+ if (codes[0].equals("\\l") || (codes[0].equals("\\L") && codes[1].equals(codes[3]))) {
+ StringBuilder s = new StringBuilder();
+ if (hexcode) {
+ s.append("0x" + codes[1].replaceFirst("^0+", "").toLowerCase() + " ");
+ }
+ s.append(Character.toChars(Integer.parseInt(codes[1], 16)));
+ if (codes[0].equals("\\L")) {
+ s.append(Character.toChars(Integer.parseInt(codes[2], 16)));
+ }
+ ow.write(s.toString() + "\n");
+ }
+ }
+ ow.write("</classes>\n");
+ ow.flush();
+ ow.close();
+ inbr.close();
+ }
+
+
+ public static void main(String[] args) throws IOException {
+ String type = "ucd", prefix = "--", infile = null, outfile = CLASSES_XML;
+ boolean hexcode = false;
+ for (int i = 0; i < args.length; ++i) {
+ if (args[i].startsWith(prefix)) {
+ String option = args[i].substring(prefix.length());
+ if (option.equals("java") || option.equals("ucd") || option.equals("tex")) {
+ type = option;
+ } else if (option.equals("hexcode")) {
+ hexcode = true;
+ } else if (option.equals("out")) {
+ outfile = args[++i];
+ } else {
+ System.err.println("Unknown option: " + option);
+ System.exit(1);
+ }
+ } else {
+ if (infile != null) {
+ System.err.println("Only one non-option argument can be given, for infile");
+ System.exit(1);
+ }
+ infile = args[i];
+ }
+ }
+
+ if (type.equals("java")) {
+ if (infile != null) {
+ System.err.println("Type java does not allow an infile");
+ System.exit(1);
+ }
+ } else {
+ if (infile == null) {
+ System.err.println("Types ucd and tex require an infile");
+ System.exit(1);
+ }
+ }
+ if (type.equals("java")) {
+ fromJava(hexcode, outfile);
+ } else if (type.equals("ucd")) {
+ fromUCD(hexcode, infile, outfile);
+ } else if (type.equals("tex")) {
+ fromTeX(hexcode, infile, outfile);
+ } else {
+ System.err.println("Unknown type: " + type + ", nothing done");
+ System.exit(1);
+ }
+ }
+
+}
Propchange: xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java
------------------------------------------------------------------------------
svn:keywords = Id
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/hyphenation/
src/java/org/apache/fop/tools/anttasks/
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Simon,
Simon Pepping wrote:
> On Wed, Aug 19, 2009 at 08:44:03AM +0200, Jeremias Maerki wrote:
>> Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
>> now on Java 1.4. OK if we revert until you've had a chance to revisit?
>
> I am surprised. My eclipse project is set to 1.4 compatibility for
> comiler compliance level, generated .class files compatibility, source
> compatibility. Which part is not compatible with 1.4?
Although the source code is 1.4-compatible, calls are made to methods
that were only added in the Java 1.5 release. So a 1.4 JRE won’t find
them.
> Revert it if that is needed to keep trunk compilable. I will not
> immediately have time to revisit this.
>
> Simon
Vincent
Re: svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./
src/java/org/apache/fop/hyphenation/
src/java/org/apache/fop/tools/anttasks/
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Wed, Aug 19, 2009 at 08:44:03AM +0200, Jeremias Maerki wrote:
> Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
> now on Java 1.4. OK if we revert until you've had a chance to revisit?
I am surprised. My eclipse project is set to 1.4 compatibility for
comiler compliance level, generated .class files compatibility, source
compatibility. Which part is not compatible with 1.4?
Revert it if that is needed to keep trunk compilable. I will not
immediately have time to revisit this.
Simon
> On 18.08.2009 22:05:01 spepping wrote:
> > Author: spepping
> > Date: Tue Aug 18 20:05:01 2009
> > New Revision: 805561
> >
> > URL: http://svn.apache.org/viewvc?rev=805561&view=rev
> > Log:
> > Prepare for new hyphenation pattern files, which do not have their own classes and instead use the default classes in FOP. Modified the build process to a forked java task, in order to be able to set a larger stack size for the compilation of the large number of classes. Added an ant task to generate a new default classes file, to be used with an update of the Unicode Character Database.
> >
> > Added:
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java (with props)
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java (with props)
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/classes.xml (with props)
> > Removed:
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/tools/anttasks/SerializeHyphPattern.java
> > Modified:
> > xmlgraphics/fop/trunk/build.properties
> > xmlgraphics/fop/trunk/build.xml
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java
> >
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
Posted by "Peter B. West" <li...@pbw.id.au>.
On 20/08/2009, at 7:41 PM, Jeremias Maerki wrote:
> There we go again. ;-) I can understand the wishes and cravings of the
> developers (feeling them myself), but as I've said before: such a
> decision should be made with the user community in the back, i.e.
> there
> should be another user survey to gather current data. Just because Sun
> EOLs a Java version doesn't mean that everyone can suddenly just do
> the
> switch. So why don't those who want this change so badly do that
> little
> survey so we have the data on an informed decision?
>
> As for retroweaving: I've just set the necessary values in my
> build-local.properties and tried to compile the latest FOP Trunk with
> Java 1.5. The build failed in the retroweaver task:
>
> -----------------------------------------------------------------------
>
> retro-avail:
> [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp
> [retroweaver] Processing 1775 classes
> [retroweaver] 1775 classes weaved.
> [retroweaver] Verifying 1775 classes
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method isLowerCase/(I)Z, The class,
> net.sourceforge.retroweaver.runtime.java.lang.Character_, c
> ould not be located: net/sourceforge/retroweaver/runtime/java/lang/
> Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method isUpperCase/(I)Z, The class,
> net.sourceforge.retroweaver.runtime.java.lang.Character_, c
> ould not be located: net/sourceforge/retroweaver/runtime/java/lang/
> Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method isTitleCase/(I)Z, Method not found in java.lang.Character
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toLowerCase/(I)I, Method not found in java.lang.Character
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method getType/(I)I, Method not found in java.lang.Character
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method of/(I)Ljava.lang.Character$UnicodeBlock;, Method not found in
> java.lang.Character$Unicod
> eBlock
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toUpperCase/(I)I, Method not found in java.lang.Character
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toTitleCase/(I)I, Method not found in java.lang.Character
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown
> method toChars/(I)[C, The class,
> net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
> r_, could not be located: net/sourceforge/retroweaver/harmony/
> runtime/java/lang/Character_
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE$EncryptionFilter:
> unknown class javax.crypto.CipherOutputStream
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method
> doFinal/([B)[B, The class, javax.crypto.Cipher, could not be
> located: javax/crypto/Cipher
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method
> getMessage/()Ljava.lang.String;, The class,
> javax.crypto.IllegalBlockSizeException, could not
> be located: javax/crypto/IllegalBlockSizeException
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method
> getMessage/()Ljava.lang.String;, The class,
> javax.crypto.BadPaddingException, could not be loc
> ated: javax/crypto/BadPaddingException
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class
> javax.crypto.Cipher
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class
> javax.crypto.IllegalBlockSizeException
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class
> javax.crypto.BadPaddingException
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class
> javax.crypto.spec.SecretKeySpec
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method
> getMessage/()Ljava.lang.String;, The class,
> javax.crypto.NoSuchPaddingException, could not be
> located: javax/crypto/NoSuchPaddingException
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class
> javax.crypto.Cipher
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class
> javax.crypto.spec.SecretKeySpec
> [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class
> javax.crypto.NoSuchPaddingException
> [retroweaver] Verification complete, 28 warning(s).
>
> BUILD FAILED
> C:\Dev\FOP\main\trunk-clean2\build.xml:519: 28 warning(s)
>
> -----------------------------------------------------------------------
>
> So that seems to indicate that the retroweaver business is not as
> simple
> as it sounds. Furthermore, has anyone done any serious tests in a
> non-trivial environment (for example an enterprise-level application
> running in an app server)? Maybe one of the stake holders around here
> that still need to support a Java 1.4 environment can do such a test
> and
> report back here?
>
> Don't get me wrong: I don't want to block this but I want this done on
> an informed basis and with a vote, not just because the developers
> like
> generics. That's reasonable, isn't it?
What makes you think that?
(Sorry - couldn't resist.)
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> There we go again. ;-) I can understand the wishes and cravings of the
> developers (feeling them myself), but as I've said before: such a
> decision should be made with the user community in the back, i.e. there
> should be another user survey to gather current data. Just because Sun
> EOLs a Java version doesn't mean that everyone can suddenly just do the
> switch. So why don't those who want this change so badly do that little
> survey so we have the data on an informed decision?
Hi All,
I'm not so against this idea 1 year further on but I still have concerns
that we would force x% of users to stay on 0.95 if we do this. I agree
with Jeremias' proposal to run a survey on fop-users for a couple of
weeks to get some hard facts to help make an informed decision.
Also, I think it is something that could wait until after the long
promised 1.0 release. With the changing IPD feature being one of the
last major features of 0.20.x missing from 0.9x that is now available we
should consider doing the v1.0 release and then if the survey shows the
number of 1.4 and earlier users to be very low then we should do the switch.
>
> As for retroweaving: I've just set the necessary values in my
> build-local.properties and tried to compile the latest FOP Trunk with
> Java 1.5. The build failed in the retroweaver task:
I would also like it if retroweaving worked if we do go ahead with the
switch to 1.5.
Thanks,
Chris
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit:
r805561 [1/2]....)
Posted by Simon Pepping <sp...@leverkruid.eu>.
Thanks for the retroweaver report.
I believe I removed all methods which are not Java 1.4 compliant.
I tried to do a compilation in Java 1.4, but I failed with an
UnsupportedClassVersionError, which I am not going to investigate
now. So I could not test this myself.
Simon
On Thu, Aug 20, 2009 at 11:41:27AM +0200, Jeremias Maerki wrote:
> As for retroweaving: I've just set the necessary values in my
> build-local.properties and tried to compile the latest FOP Trunk with
> Java 1.5. The build failed in the retroweaver task:
>
> -----------------------------------------------------------------------
>
> retro-avail:
> [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp
> [retroweaver] Processing 1775 classes
> [retroweaver] 1775 classes weaved.
> [retroweaver] Verifying 1775 classes
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c
> ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_
> [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c
> ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_
...
> BUILD FAILED
> C:\Dev\FOP\main\trunk-clean2\build.xml:519: 28 warning(s)
>
> > >
> > > Jeremias Maerki wrote:
> > >> Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
> > >> now on Java 1.4. OK if we revert until you've had a chance to revisit?
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 24.08.2009 14:04:13 Laurent Caillette wrote:
> Hi all,
>
> A few thoughts about Java 1.5 support and FOP version numbers.
>
> I suggest to keep the emblematic "1.0" for the full support of the
> XSLT-1.0 spec. I don't see any problem with FOP version hitting 0.99 or
> even 0.123 one day.
I do. We don't currently have the resources available to even hope for
achieving something close to 100% spec coverage within the next 5 years
(judging from the progress lately). And some people simply don't use 0.x
software. Some companies have strict policies in that direction (even if
that's stupid in FOP's case). But we've had that discussion before and
decided to go 1.0 with the next release. Maybe going 1.0 will give FOP more
visibility and there's a minimal chance that it will attract new
contributors in the future. FOP turns 10 in a couple of months and still
being 0.x is a joke in itself IMO.
> Java 5 as minimum requirement sounds good to me (while another version
> with 1.4 sounds reasonable, too). But Java 6 is too high as minimum
> requirement. Java 5 is still the default JVM on Mac.
Agreed.
> Hope this helps,
>
> c.
>
>
Jeremias Maerki
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by "Peter B. West" <li...@pbw.id.au>.
On 03/09/2009, at 6:51 PM, Max Berger wrote:
> Dear Fop Devs,
>
> Peter B. West schrieb:
>> Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit
>> machines. Apple's commitment to Java has slackened off considerably.
>> Peter
>
> Just for the mail archives: Snow Leopard (Mac OS X 10.6) includes
> Java 6
> on 32-bit intel architectures [and was not yet released at the time of
> the original post].
Thanks Max. Very good news.
Peter
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Max Berger <ma...@berger.name>.
Dear Fop Devs,
Peter B. West schrieb:
> Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit
> machines. Apple's commitment to Java has slackened off considerably.
> Peter
Just for the mail archives: Snow Leopard (Mac OS X 10.6) includes Java 6
on 32-bit intel architectures [and was not yet released at the time of
the original post].
Max
--
http://max.berger.name/
OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by "Peter B. West" <li...@pbw.id.au>.
On 24/08/2009, at 10:04 PM, Laurent Caillette wrote:
> Hi all,
>
> A few thoughts about Java 1.5 support and FOP version numbers.
>
> I suggest to keep the emblematic "1.0" for the full support of the
> XSLT-1.0 spec. I don't see any problem with FOP version hitting 0.99
> or even 0.123 one day.
>
> Java 5 as minimum requirement sounds good to me (while another
> version with 1.4 sounds reasonable, too). But Java 6 is too high as
> minimum requirement. Java 5 is still the default JVM on Mac.
>
> Hope this helps,
>
> c.
Java 6 is, as yet, and possibly indefinitely, unavailable for 32 bit
machines. Apple's commitment to Java has slackened off considerably.
Peter
RE: Moving to Java 1.5, retroweaving for 1.4
Posted by Laurent Caillette <La...@ullink.com>.
Hi all,
A few thoughts about Java 1.5 support and FOP version numbers.
I suggest to keep the emblematic "1.0" for the full support of the XSLT-1.0 spec. I don't see any problem with FOP version hitting 0.99 or even 0.123 one day.
Java 5 as minimum requirement sounds good to me (while another version with 1.4 sounds reasonable, too). But Java 6 is too high as minimum requirement. Java 5 is still the default JVM on Mac.
Hope this helps,
c.
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4362 (20090824) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 25.08.2009 20:38:19 Simon Pepping wrote:
> On Tue, Aug 25, 2009 at 12:11:34PM +0100, Vincent Hennebert wrote:
> > Hi Clay,
> >
> > The Web Maestro wrote:
> > > I agree about consistency w requirements... Perhaps one additional
> > > release req 1.4, then move to 1.5 for the next release. I don't have
> > > any real energy about whether the 1.0 should be 1.4 or 1.5, however...
> > > I do agree that there should be a significant version change
> > > signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)?
> > > If FOP is going to switch anyway, is there a compelling reason not to
> > > req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the
> > > jump)? Would that lock out a huge number of our audience? Would
> > > requiring 1.6 mean any significant performance or other benefit?
> >
> > According to this thread the majority seems to go along with releasing
> > a Java 1.4 compliant, 1.0 version. There would be a significant change
>
> Agreed.
Agreed.
> > in the number of the following release, along with a jump to Java 1.5 as
> > a minimum requirement. That???s fine by me.
>
> Not agreed. There were two remarks about the version number. That part
> remains open.
I don't think it's that important at the moment. Let's worry about the
next release first.
> > I propose to launch the poll shortly after the release of 1.0.
>
> Very well.
>
> Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
Jeremias Maerki
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Chris Bowditch <bo...@hotmail.com>.
Vincent Hennebert wrote:
Hi Vincent,
> I’d say it the other way round: I think that there is no compelling
> reason to switch to Java 1.6. Apart maybe from the internationalization
> area, the improvements made in that version are not likely to be that
> much of a benefit for FOP to justify the jump.
>
> Of course, that doesn’t prevent users from running FOP with a 1.6 JVM,
> and take advantage of the performance improvements made in that release.
>
> According to this thread the majority seems to go along with releasing
> a Java 1.4 compliant, 1.0 version. There would be a significant change
> in the number of the following release, along with a jump to Java 1.5 as
> a minimum requirement. That’s fine by me.
>
> I propose to launch the poll shortly after the release of 1.0.
yes I agree with your summary above.
Thanks,
Chris
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Tue, Aug 25, 2009 at 12:11:34PM +0100, Vincent Hennebert wrote:
> Hi Clay,
>
> The Web Maestro wrote:
> > I agree about consistency w requirements... Perhaps one additional
> > release req 1.4, then move to 1.5 for the next release. I don't have
> > any real energy about whether the 1.0 should be 1.4 or 1.5, however...
> > I do agree that there should be a significant version change
> > signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)?
> > If FOP is going to switch anyway, is there a compelling reason not to
> > req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the
> > jump)? Would that lock out a huge number of our audience? Would
> > requiring 1.6 mean any significant performance or other benefit?
>
> According to this thread the majority seems to go along with releasing
> a Java 1.4 compliant, 1.0 version. There would be a significant change
Agreed.
> in the number of the following release, along with a jump to Java 1.5 as
> a minimum requirement. That???s fine by me.
Not agreed. There were two remarks about the version number. That part
remains open.
> I propose to launch the poll shortly after the release of 1.0.
Very well.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Clay,
The Web Maestro wrote:
> I agree about consistency w requirements... Perhaps one additional
> release req 1.4, then move to 1.5 for the next release. I don't have
> any real energy about whether the 1.0 should be 1.4 or 1.5, however...
> I do agree that there should be a significant version change
> signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)?
> If FOP is going to switch anyway, is there a compelling reason not to
> req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the
> jump)? Would that lock out a huge number of our audience? Would
> requiring 1.6 mean any significant performance or other benefit?
I’d say it the other way round: I think that there is no compelling
reason to switch to Java 1.6. Apart maybe from the internationalization
area, the improvements made in that version are not likely to be that
much of a benefit for FOP to justify the jump.
Of course, that doesn’t prevent users from running FOP with a 1.6 JVM,
and take advantage of the performance improvements made in that release.
According to this thread the majority seems to go along with releasing
a Java 1.4 compliant, 1.0 version. There would be a significant change
in the number of the following release, along with a jump to Java 1.5 as
a minimum requirement. That’s fine by me.
I propose to launch the poll shortly after the release of 1.0.
<snip/>
Vincent
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by The Web Maestro <th...@gmail.com>.
I agree about consistency w requirements... Perhaps one additional
release req 1.4, then move to 1.5 for the next release. I don't have
any real energy about whether the 1.0 should be 1.4 or 1.5, however...
I do agree that there should be a significant version change
signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)?
If FOP is going to switch anyway, is there a compelling reason not to
req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the
jump)? Would that lock out a huge number of our audience? Would
requiring 1.6 mean any significant performance or other benefit?
Clay
On 8/22/09, Max Berger <ma...@berger.name> wrote:
> Dear Fop-Devs,
>
> since I am one of the people cited for moving forward to 1.5, I just
> want to throw my 2 cts in the mix:
>
> I would prefer a new release first, and then moving to 1.5.
>
> Rationale:
>
> 1) Retroweaving works, but there will be some bugs which will have to
> be ironed out and tested. The last release (0.95) has been done quite
> a long time back, and the next release will take even longer when a
> new "feature" (1.5) is added.
>
> 2) Since the 0.9x releases are "test-releases" towards 1.0, they
> should have the same features / requirements.
>
> 3) The next release (1.0.9x ? 1.9x?) could then depend on 1.5, whereas
> the 1.0 branch could stay on 1.4
>
> As an example from another apache project: Maven moved from 2.1.0 to
> 2.2.0 rather than 2.1.x because they now require java 1.5 and did not
> want to make this a "minor" upgrade"
>
> Max
>
> 2009/8/20 Simon Pepping <sp...@leverkruid.eu>:
>> On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote:
>>> Jeremias Maerki wrote:
>>> >There we go again. ;-) I can understand the wishes and cravings of the
>>> >developers (feeling them myself), but as I've said before: such a
>>> >decision should be made with the user community in the back, i.e. there
>>> >should be another user survey to gather current data. Just because Sun
>>> >EOLs a Java version doesn't mean that everyone can suddenly just do the
>>> >switch. So why don't those who want this change so badly do that little
>>> >survey so we have the data on an informed decision?
>>>
>>> Hi All,
>>>
>>> I'm not so against this idea 1 year further on but I still have
>>> concerns that we would force x% of users to stay on 0.95 if we do
>>> this. I agree with Jeremias' proposal to run a survey on fop-users
>>> for a couple of weeks to get some hard facts to help make an
>>> informed decision.
>>>
>>> Also, I think it is something that could wait until after the long
>>> promised 1.0 release. With the changing IPD feature being one of the
>>> last major features of 0.20.x missing from 0.9x that is now
>>> available we should consider doing the v1.0 release and then if the
>>> survey shows the number of 1.4 and earlier users to be very low then
>>> we should do the switch.
>>
>> I agree that we should proceed with a 1.0 release.
>>
>> I can also agree with releasing it compliant with Java 1.4.
>>
>> I note, however, that the methods I removed were several methods in
>> class Character which are very useful in character handling, such as
>> the method Character.toChars(int), which is the main method to convert
>> an integer to an array of chars. That means that for Unicode values
>> above 0xFFFF there is no good method to turn the value into a char[]
>> or String. Also Characters.toLowerCase, toUpperCase, toTitleCase,
>> getType, $UnicodeBlock. For a text handling application in 2009 that
>> is a bit painful.
>>
>> Simon
>>
>> --
>> Simon Pepping
>> home page: http://www.leverkruid.eu
>>
>
--
Regards,
The Web Maestro
--
<th...@gmail.com> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Max Berger <ma...@berger.name>.
Dear Fop-Devs,
since I am one of the people cited for moving forward to 1.5, I just
want to throw my 2 cts in the mix:
I would prefer a new release first, and then moving to 1.5.
Rationale:
1) Retroweaving works, but there will be some bugs which will have to
be ironed out and tested. The last release (0.95) has been done quite
a long time back, and the next release will take even longer when a
new "feature" (1.5) is added.
2) Since the 0.9x releases are "test-releases" towards 1.0, they
should have the same features / requirements.
3) The next release (1.0.9x ? 1.9x?) could then depend on 1.5, whereas
the 1.0 branch could stay on 1.4
As an example from another apache project: Maven moved from 2.1.0 to
2.2.0 rather than 2.1.x because they now require java 1.5 and did not
want to make this a "minor" upgrade"
Max
2009/8/20 Simon Pepping <sp...@leverkruid.eu>:
> On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote:
>> Jeremias Maerki wrote:
>> >There we go again. ;-) I can understand the wishes and cravings of the
>> >developers (feeling them myself), but as I've said before: such a
>> >decision should be made with the user community in the back, i.e. there
>> >should be another user survey to gather current data. Just because Sun
>> >EOLs a Java version doesn't mean that everyone can suddenly just do the
>> >switch. So why don't those who want this change so badly do that little
>> >survey so we have the data on an informed decision?
>>
>> Hi All,
>>
>> I'm not so against this idea 1 year further on but I still have
>> concerns that we would force x% of users to stay on 0.95 if we do
>> this. I agree with Jeremias' proposal to run a survey on fop-users
>> for a couple of weeks to get some hard facts to help make an
>> informed decision.
>>
>> Also, I think it is something that could wait until after the long
>> promised 1.0 release. With the changing IPD feature being one of the
>> last major features of 0.20.x missing from 0.9x that is now
>> available we should consider doing the v1.0 release and then if the
>> survey shows the number of 1.4 and earlier users to be very low then
>> we should do the switch.
>
> I agree that we should proceed with a 1.0 release.
>
> I can also agree with releasing it compliant with Java 1.4.
>
> I note, however, that the methods I removed were several methods in
> class Character which are very useful in character handling, such as
> the method Character.toChars(int), which is the main method to convert
> an integer to an array of chars. That means that for Unicode values
> above 0xFFFF there is no good method to turn the value into a char[]
> or String. Also Characters.toLowerCase, toUpperCase, toTitleCase,
> getType, $UnicodeBlock. For a text handling application in 2009 that
> is a bit painful.
>
> Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>
Re: Moving to Java 1.5, retroweaving for 1.4
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote:
> Jeremias Maerki wrote:
> >There we go again. ;-) I can understand the wishes and cravings of the
> >developers (feeling them myself), but as I've said before: such a
> >decision should be made with the user community in the back, i.e. there
> >should be another user survey to gather current data. Just because Sun
> >EOLs a Java version doesn't mean that everyone can suddenly just do the
> >switch. So why don't those who want this change so badly do that little
> >survey so we have the data on an informed decision?
>
> Hi All,
>
> I'm not so against this idea 1 year further on but I still have
> concerns that we would force x% of users to stay on 0.95 if we do
> this. I agree with Jeremias' proposal to run a survey on fop-users
> for a couple of weeks to get some hard facts to help make an
> informed decision.
>
> Also, I think it is something that could wait until after the long
> promised 1.0 release. With the changing IPD feature being one of the
> last major features of 0.20.x missing from 0.9x that is now
> available we should consider doing the v1.0 release and then if the
> survey shows the number of 1.4 and earlier users to be very low then
> we should do the switch.
I agree that we should proceed with a 1.0 release.
I can also agree with releasing it compliant with Java 1.4.
I note, however, that the methods I removed were several methods in
class Character which are very useful in character handling, such as
the method Character.toChars(int), which is the main method to convert
an integer to an array of chars. That means that for Unicode values
above 0xFFFF there is no good method to turn the value into a char[]
or String. Also Characters.toLowerCase, toUpperCase, toTitleCase,
getType, $UnicodeBlock. For a text handling application in 2009 that
is a bit painful.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
There we go again. ;-) I can understand the wishes and cravings of the
developers (feeling them myself), but as I've said before: such a
decision should be made with the user community in the back, i.e. there
should be another user survey to gather current data. Just because Sun
EOLs a Java version doesn't mean that everyone can suddenly just do the
switch. So why don't those who want this change so badly do that little
survey so we have the data on an informed decision?
As for retroweaving: I've just set the necessary values in my
build-local.properties and tried to compile the latest FOP Trunk with
Java 1.5. The build failed in the retroweaver task:
-----------------------------------------------------------------------
retro-avail:
[mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp
[retroweaver] Processing 1775 classes
[retroweaver] 1775 classes weaved.
[retroweaver] Verifying 1775 classes
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c
ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c
ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isTitleCase/(I)Z, Method not found in java.lang.Character
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toLowerCase/(I)I, Method not found in java.lang.Character
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method getType/(I)I, Method not found in java.lang.Character
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method of/(I)Ljava.lang.Character$UnicodeBlock;, Method not found in java.lang.Character$Unicod
eBlock
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toUpperCase/(I)I, Method not found in java.lang.Character
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toTitleCase/(I)I, Method not found in java.lang.Character
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte
r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE$EncryptionFilter: unknown class javax.crypto.CipherOutputStream
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method doFinal/([B)[B, The class, javax.crypto.Cipher, could not be located: javax/crypto/Cipher
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.IllegalBlockSizeException, could not
be located: javax/crypto/IllegalBlockSizeException
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.BadPaddingException, could not be loc
ated: javax/crypto/BadPaddingException
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class javax.crypto.Cipher
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class javax.crypto.IllegalBlockSizeException
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class javax.crypto.BadPaddingException
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class javax.crypto.spec.SecretKeySpec
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.NoSuchPaddingException, could not be
located: javax/crypto/NoSuchPaddingException
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class javax.crypto.Cipher
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class javax.crypto.spec.SecretKeySpec
[retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown class javax.crypto.NoSuchPaddingException
[retroweaver] Verification complete, 28 warning(s).
BUILD FAILED
C:\Dev\FOP\main\trunk-clean2\build.xml:519: 28 warning(s)
-----------------------------------------------------------------------
So that seems to indicate that the retroweaver business is not as simple
as it sounds. Furthermore, has anyone done any serious tests in a
non-trivial environment (for example an enterprise-level application
running in an app server)? Maybe one of the stake holders around here
that still need to support a Java 1.4 environment can do such a test and
report back here?
Don't get me wrong: I don't want to block this but I want this done on
an informed basis and with a vote, not just because the developers like
generics. That's reasonable, isn't it?
On 19.08.2009 19:28:25 Vincent Hennebert wrote:
> Adrian Cumiskey wrote:
> > Hi all,
> >
> > Maybe its time we moved to 1.5 like the rest of the world. Max, Vincent
> > and Andreas, myself and others were all in favour of the switch in June
> > 2008 (see http://www.nabble.com/Switching-to-Java-1.5-td17673100.html).
> > Sun's end of life transition period for 1.4 ended on October 30th,
> > 2008. I personally think we can now safely retroweave to 1.4.
>
> +1
>
> Although we don’t even need to discuss that in the context of Simon’s
> change, IMO. Like the comment says in the build.xml file, the task
> doesn’t need to be run at every build. So 1.4 compatibility still is
> available.
>
> OTOH, the new UnicodeClasses class has quite a few checkstyle warnings
> that it would be good if they were fixed.
>
> Also, I have concerns about putting the generated classes.xml file
> inside the src/java directory. I’d rather not mix generated files with
> manually edited ones. What about a new hyphenation directory in
> src/codegen?
>
>
> Thanks,
> Vincent
>
>
> > Adrian.
> >
> > Jeremias Maerki wrote:
> >> Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
> >> now on Java 1.4. OK if we revert until you've had a chance to revisit?
> >>
> >> On 18.08.2009 22:05:01 spepping wrote:
> >>
> >>> Author: spepping
> >>> Date: Tue Aug 18 20:05:01 2009
> >>> New Revision: 805561
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=805561&view=rev
> >>> Log:
> >>> Prepare for new hyphenation pattern files, which do not have their
> >>> own classes and instead use the default classes in FOP. Modified the
> >>> build process to a forked java task, in order to be able to set a
> >>> larger stack size for the compilation of the large number of classes.
> >>> Added an ant task to generate a new default classes file, to be used
> >>> with an update of the Unicode Character Database.
> >>>
> >>> Added:
> >>>
> >>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java
> >>> (with props)
> >>>
> >>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java
> >>> (with props)
> >>>
> >>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/classes.xml
> >>> (with props)
> >>> Removed:
> >>>
> >>> xmlgraphics/fop/trunk/src/java/org/apache/fop/tools/anttasks/SerializeHyphPattern.java
> >>>
> >>> Modified:
> >>> xmlgraphics/fop/trunk/build.properties
> >>> xmlgraphics/fop/trunk/build.xml
> >>>
> >>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> Jeremias Maerki
Jeremias Maerki
Re: svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./
src/java/org/apache/fop/hyphenation/
src/java/org/apache/fop/tools/anttasks/
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Wed, Aug 19, 2009 at 06:28:25PM +0100, Vincent Hennebert wrote:
> OTOH, the new UnicodeClasses class has quite a few checkstyle warnings
> that it would be good if they were fixed.
I will try to run that.
> Also, I have concerns about putting the generated classes.xml file
> inside the src/java directory. I???d rather not mix generated files with
> manually edited ones. What about a new hyphenation directory in
> src/codegen?
What about src/codegen/unicode/data, which already has
LineBreakPairTable.txt.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/hyphenation/
src/java/org/apache/fop/tools/anttasks/
Posted by Vincent Hennebert <vh...@gmail.com>.
Adrian Cumiskey wrote:
> Hi all,
>
> Maybe its time we moved to 1.5 like the rest of the world. Max, Vincent
> and Andreas, myself and others were all in favour of the switch in June
> 2008 (see http://www.nabble.com/Switching-to-Java-1.5-td17673100.html).
> Sun's end of life transition period for 1.4 ended on October 30th,
> 2008. I personally think we can now safely retroweave to 1.4.
+1
Although we don’t even need to discuss that in the context of Simon’s
change, IMO. Like the comment says in the build.xml file, the task
doesn’t need to be run at every build. So 1.4 compatibility still is
available.
OTOH, the new UnicodeClasses class has quite a few checkstyle warnings
that it would be good if they were fixed.
Also, I have concerns about putting the generated classes.xml file
inside the src/java directory. I’d rather not mix generated files with
manually edited ones. What about a new hyphenation directory in
src/codegen?
Thanks,
Vincent
> Adrian.
>
> Jeremias Maerki wrote:
>> Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
>> now on Java 1.4. OK if we revert until you've had a chance to revisit?
>>
>> On 18.08.2009 22:05:01 spepping wrote:
>>
>>> Author: spepping
>>> Date: Tue Aug 18 20:05:01 2009
>>> New Revision: 805561
>>>
>>> URL: http://svn.apache.org/viewvc?rev=805561&view=rev
>>> Log:
>>> Prepare for new hyphenation pattern files, which do not have their
>>> own classes and instead use the default classes in FOP. Modified the
>>> build process to a forked java task, in order to be able to set a
>>> larger stack size for the compilation of the large number of classes.
>>> Added an ant task to generate a new default classes file, to be used
>>> with an update of the Unicode Character Database.
>>>
>>> Added:
>>>
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java
>>> (with props)
>>>
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java
>>> (with props)
>>>
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/classes.xml
>>> (with props)
>>> Removed:
>>>
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/tools/anttasks/SerializeHyphPattern.java
>>>
>>> Modified:
>>> xmlgraphics/fop/trunk/build.properties
>>> xmlgraphics/fop/trunk/build.xml
>>>
>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java
>>>
>>>
>>>
>>
>>
>>
>> Jeremias Maerki
Re: svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/hyphenation/
src/java/org/apache/fop/tools/anttasks/
Posted by Adrian Cumiskey <de...@cumiskey.com>.
Hi all,
Maybe its time we moved to 1.5 like the rest of the world. Max, Vincent
and Andreas, myself and others were all in favour of the switch in June
2008 (see http://www.nabble.com/Switching-to-Java-1.5-td17673100.html).
Sun's end of life transition period for 1.4 ended on October 30th,
2008. I personally think we can now safely retroweave to 1.4.
Adrian.
Jeremias Maerki wrote:
> Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
> now on Java 1.4. OK if we revert until you've had a chance to revisit?
>
> On 18.08.2009 22:05:01 spepping wrote:
>
>> Author: spepping
>> Date: Tue Aug 18 20:05:01 2009
>> New Revision: 805561
>>
>> URL: http://svn.apache.org/viewvc?rev=805561&view=rev
>> Log:
>> Prepare for new hyphenation pattern files, which do not have their own classes and instead use the default classes in FOP. Modified the build process to a forked java task, in order to be able to set a larger stack size for the compilation of the large number of classes. Added an ant task to generate a new default classes file, to be used with an update of the Unicode Character Database.
>>
>> Added:
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java (with props)
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java (with props)
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/classes.xml (with props)
>> Removed:
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/tools/anttasks/SerializeHyphPattern.java
>> Modified:
>> xmlgraphics/fop/trunk/build.properties
>> xmlgraphics/fop/trunk/build.xml
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java
>>
>>
>
>
>
> Jeremias Maerki
>
>
>
Re: svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/hyphenation/ src/java/org/apache/fop/tools/anttasks/
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Uhm, Simon, this change uses tons of Java 1.5 features. The build fails
now on Java 1.4. OK if we revert until you've had a chance to revisit?
On 18.08.2009 22:05:01 spepping wrote:
> Author: spepping
> Date: Tue Aug 18 20:05:01 2009
> New Revision: 805561
>
> URL: http://svn.apache.org/viewvc?rev=805561&view=rev
> Log:
> Prepare for new hyphenation pattern files, which do not have their own classes and instead use the default classes in FOP. Modified the build process to a forked java task, in order to be able to set a larger stack size for the compilation of the large number of classes. Added an ant task to generate a new default classes file, to be used with an update of the Unicode Character Database.
>
> Added:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/SerializeHyphPattern.java (with props)
> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/UnicodeClasses.java (with props)
> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/classes.xml (with props)
> Removed:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/tools/anttasks/SerializeHyphPattern.java
> Modified:
> xmlgraphics/fop/trunk/build.properties
> xmlgraphics/fop/trunk/build.xml
> xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/PatternParser.java
>
Jeremias Maerki