OpenOffice hyphenation in Java - YESSSSSS
Look what I've just found: http://linux.org.mt/projects/jtextcheck/jtextcheck-ooohyph-plugin/index.html It's LGPL (and so are OO's hyphenation patterns if I remember correctly) but if we provide a plug-in mechanism and host the actual adapter under the LGPL at http://offo.sourceforge.net/ we could provide the same hyphenation functionality as OO. Info on LGPL use by Apache software: http://wiki.apache.org/jakarta/Using_20LGPL_27d_20code http://wiki.apache.org/jakarta/LicenceIssues Now, can we please get rid of all hyphenation patterns in FOP? Please, please. Just joking, but I'd feel better. Jeremias Maerki
Re: Project offo distributes hyphenation pattern files for FOP
Thanks for setting this up, Simon. Please let me know if there is anything I can do to help. Web Maestro Clay Simon Pepping wrote: Dear FOP users, In February 2004 a large number of hyphenation pattern files were removed from FOP's CVS repository due to licensing issues. These hyphenation patterns were contributed to FOP under licenses which allowed their free distribution, but under conditions which were felt to be in contradiction with the Apache license, under which FOP is distributed. Most files are licensed under the LaTeX Project Public License (http://www.latex-project.org/lppl/index.html), which requires that no modified version be published under the name of the original source file. For details see the FOP wiki page (http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003). I am please to announce that the hyphenation pattern files for FOP are now made available by the project `Objects for Formatting Objects' (offo) (http://offo.sourceforge.net/). They can be downloaded from offo's project page (http://sourceforge.net/projects/offo/). At this moment the homepage of the project is not yet ready. Therefore the overview of the hyphenation pattern files and their licenses is available from my web site, http://www.leverkruid.nl/FOP/hyphenation.html. It is also contained in the package file. Regards, Simon -- Peter B. West http://cv.pbw.id.au/
Re: Project offo distributes hyphenation pattern files for FOP
On Mon, Sep 13, 2004 at 08:03:08AM -0700, Clay Leeds wrote: Thanks for setting this up, Simon. Please let me know if there is anything I can do to help. Thanks for the offer. It was some work to set this up, although I could build mostly on Jeremias' earlier work. I expect that from now on the project will not give me much work. The only thing that needs to happen, is a nicer design for the home page and the page hyphenation.html. Perhaps a challenge for the web master? It might be a good idea if you or someone else of the FOP team would also be a project administrator, to make it less dependent on one person. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Project offo distributes hyphenation pattern files for FOP
On Sun, Sep 12, 2004 at 11:35:42AM +1000, Peter B. West wrote: Moved from fop-user. Simon, Under which license have you set up the SourceForge project? I stated that contributions with any OSI-approved license or in the Public Domain were acceptable. The discussion to get the idea explained and this license statement accepted was lengthy. I took care to state each license carefully in the covering page http://sourceforge.net/offo/hyphenation.html. For a large part thanks to Jeremias earlier work. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Project offo distributes hyphenation pattern files for FOP
On Sep 13, 2004, at 11:51 AM, Simon Pepping wrote: On Mon, Sep 13, 2004 at 08:03:08AM -0700, Clay Leeds wrote: Thanks for setting this up, Simon. Please let me know if there is anything I can do to help. Thanks for the offer. It was some work to set this up, although I could build mostly on Jeremias' earlier work. I expect that from now on the project will not give me much work. The only thing that needs to happen, is a nicer design for the home page and the page hyphenation.html. Perhaps a challenge for the web master? I'd be happy to spend some time on this. I've got a couple ideas and will see if I can't come up with something soon. It might be a good idea if you or someone else of the FOP team would also be a project administrator, to make it less dependent on one person. Regards, Simon Again, I'd be happy to oblige. I can also be another project administrator if you'd like. Web Maestro Clay
Re: Project offo distributes hyphenation pattern files for FOP
Moved from fop-user. Simon, Under which license have you set up the SourceForge project? Peter Simon Pepping wrote: Dear FOP users, In February 2004 a large number of hyphenation pattern files were removed from FOP's CVS repository due to licensing issues. These hyphenation patterns were contributed to FOP under licenses which allowed their free distribution, but under conditions which were felt to be in contradiction with the Apache license, under which FOP is distributed. Most files are licensed under the LaTeX Project Public License (http://www.latex-project.org/lppl/index.html), which requires that no modified version be published under the name of the original source file. For details see the FOP wiki page (http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003). I am please to announce that the hyphenation pattern files for FOP are now made available by the project `Objects for Formatting Objects' (offo) (http://offo.sourceforge.net/). They can be downloaded from offo's project page (http://sourceforge.net/projects/offo/). At this moment the homepage of the project is not yet ready. Therefore the overview of the hyphenation pattern files and their licenses is available from my web site, http://www.leverkruid.nl/FOP/hyphenation.html. It is also contained in the package file. Regards, Simon -- Peter B. West http://cv.pbw.id.au/
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-05-29 08:56 --- Applied. Thanks. Simon
DO NOT REPLY [Bug 28431] - [PATCH] Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 [PATCH] Hyphenation of words with punctuation marks [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-05-29 09:20 --- Patch applied. Thanks. Simon
Re: User configuration for hyphenation
Glen Mazza wrote: I believe the same logger reference would just be used with each thread instead, es, and this is exactly the problem. It is conceivable that different loggers might be used for different processors which run in concurrent threads. A static logger reference prohibits this. J.Pietschmann
Re: User configuration for hyphenation
J.Pietschmann wrote: Glen Mazza wrote: I believe the same logger reference would just be used with each thread instead, es, and this is exactly the problem. It is conceivable that different loggers might be used for different processors which run in concurrent threads. A static logger reference prohibits this. However, the logger naming is purely conventional (at least in 1.4 logging), so if the need for different logging in different threads arose, it could be accommodated by appending a thread-based suffix to the logger name. Or was there some other problem you had in mind here? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: User configuration for hyphenation
On Sun, May 09, 2004 at 11:52:31AM -0400, Glen Mazza wrote: Joerg I believe just recommended storing the user configuration in FOUserAgent, which is already getting passed around everywhere. Using my favorite design pattern, Moving Part Reduction, I also think it would be ideal if we could place all of this in FOUserAgent. (I also suspect that much of what will be in FOUserAgent/User configuration will be variable over time, which may also suggest we keep this all in one class.) BTW, what other things besides hyphenation needs to go into user configuration/fo user agent, say for 1.0? I like Joerg's idea of a Global Context object. It seems to have a wider scope than FOUserAgent. An FOUserAgent object could be part of it. From the maintenance code's configuration it would need to have baseDir, fontBaseDir, hyphenation-dir and strokeSVGText. Font information per renderer has already been implemented; only the pdf renderer really uses it. PDF filter lists have also been implemented in the pdf renderer. Two more observations: 1.) What does the team think of placing all the FOUserAgent information into the abstract apps.InputHandler class by either (a) full incorporation (i.e., getting rid of FOUserAgent and moving everything in it to InputHandler), or (b) including an FOUserAgent instance variable in apps.InputHandler, or (c) having InputHandler extend FOUserAgent? Then, we would just pass InputHandler around instead of FOUserAgent. I mention this because InputHandler includes the file name information already, that is sometimes good to have at various parts of the pipeline (for example, error messages or AWTRenderer, whose refresh capability requires knowing the input source file names.) I'm not sure of the value of this idea, but am just bringing it up for others to comment. I would prefer input file information in the Global Context object. InputHandler has more information than needed elsewhere in the process. 2.) For the fop.image package, and future packages which have a high chance of being used for transcoder or other non-FOP purposes, I'd like us to factor out the FOUserAgent. We had a small problem a few months back when Thomas DeWeese was updating our fop.image package for the transcoder and had trouble trying to figure out how to create an FOUserAgent in order to supply a method parameter. (Turned out only a logger within FOUserAgent was being used, so I changed the method signature to just require that.) More generally, explicitly send in the needed values from FOUserAgent into the called package (eliminating the need for other callees to create an FOUserAgent instance), or, for those packages which require lots of variables in order to be properly initialized, create the collection class (i.e., like a ImageUserAgent) in that package, not in the callee's package. Then *any* callee can just import that collection class, fill it up, and send it back to the called package. Would this not be modelled by a set of interfaces? Packages or other parts of FOP could define interfaces providing the information they need. A Global Context would probably implement them all. Users addressing only part of FOP may create their own implementation of the relevant interface. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: User configuration for hyphenation
Simon Pepping wrote: I like Joerg's idea of a Global Context object. It seems to have a wider scope than FOUserAgent. An FOUserAgent object could be part of it. From the maintenance code's configuration it would need to have baseDir, fontBaseDir, hyphenation-dir and strokeSVGText. Font information per renderer has already been implemented; only the pdf renderer really uses it. PDF filter lists have also been implemented in the pdf renderer. Sounds good to me. While we're on the subject of '*Dir' configuration, now may be a good time to rename the hyphenation-dir object to something that is consistent with the other directory-related items: hyphenationBaseDir We could also shorten the name to something like 'hyphBaseDir', but I don't think it's worth it. Better to have clear names (and naming conventions). On Sun, May 09, 2004 at 11:52:31AM -0400, Glen Mazza wrote: snip what=FoUserAgent stuff Two more observations: 1.) What does the team think of placing all the FOUserAgent information into the abstract apps.InputHandler class by either (a) full incorporation (i.e., getting rid of FOUserAgent and moving everything in it to InputHandler), or (b) including an FOUserAgent instance variable in apps.InputHandler, or (c) having InputHandler extend FOUserAgent? Then, we would just pass InputHandler around instead of FOUserAgent. I mention this because InputHandler includes the file name information already, that is sometimes good to have at various parts of the pipeline (for example, error messages or AWTRenderer, whose refresh capability requires knowing the input source file names.) I'm not sure of the value of this idea, but am just bringing it up for others to comment. I would prefer input file information in the Global Context object. InputHandler has more information than needed elsewhere in the process. It's not clear to me how these changes would affect things, but I would hope the following remains true: If FOP is 'compartmentalized' (modularized, etc.) to enable embedded or external 'non-FOP' usage, I would hope that any of the changes to FOUserAgent being discussed, do not impact integration via external usage (be it, cocoon, forrest or some other un-dreamed-of tool). In other words, my hope is that these types of changes to FOP make it even more desirable as a product to 'build on' than it already is. Web Maestro Clay
Re: User configuration for hyphenation
J.Pietschmann wrote: Mutable static data, like a static logger reference, interferes severely with using FOP in an MT environment, because this means one thread rendering globally rather than one thread per FO processor rendering, perhaps using multiple processors, each one in a separate thread. I believe the same logger reference would just be used with each thread instead, written to by multiple threads (which is another problem, but not this one.) Further, commons loggers are instantiated with a log name, usually the class name where it appears, with the same logger used only if the log name is the same. We probably still have some unnecessary get/set logger references, such as in FOUserAgent, no longer needed due to the architecture of Commons Logging (i.e., any class doing logging can now call a LogFactory to get a logging instance.) Getting rid of them would possibly alleviate some of these issues. Also, I'm not certain of the need for logging, at least to the degree that we are doing it--many other applications at our level or below--Xerces, Xalan, Batik, compilers--don't bother with it, relying on System.out/err.println() or glorified versions thereof. Glen
Re: User configuration for hyphenation
Simon Pepping wrote: But hyphenation is done deep down in the process, where any reference to the start-up objects is lost. How can I configure it? The idea is to use an object which represents some global context and is reachable from nearly anywhere in the FO tree and LM tree. I'd think the user agent should qualify. Static objects are bad because of the usual MT issues (yeah, even for logging). J.Pietschmann
Re: User configuration for hyphenation
J.Pietschmann wrote: Static objects are bad because of the usual MT issues (yeah, even for logging). Should FOP itself multithread, or would it be better to let whatever would call FOP do the multithreading? I don't know what Xalan does with their translets, I suspect they just rely on the caller to implement it. Also, would implementation of FOP MT cause the caller's MT to become inefficient or otherwise messed up? I think I can see more use cases of letting FOP's caller handle the MT (e.g., servlet implementing MT to return PDF's simultaneously to hundreds of users, one PDF generation on each thread) than of FOP doing it itself, at the same time the caller has implemented it. Glen
Re: User configuration for hyphenation
Jeremias Maerki wrote: The first two frames are in static context. The LMs share a reference to a user agent object, of type layoutmgr.AbstractLayoutManager.userAgent. Would this be the right object to hold a reference to the user configuration? On first thought, yes. But I feel the scope of the FOUserAgent is still somewhat undefined. Maybe we need to finally settle this issue. Until this is done I consider it safe to hold the user configuration in there. Joerg I believe just recommended storing the user configuration in FOUserAgent, which is already getting passed around everywhere. Using my favorite design pattern, Moving Part Reduction, I also think it would be ideal if we could place all of this in FOUserAgent. (I also suspect that much of what will be in FOUserAgent/User configuration will be variable over time, which may also suggest we keep this all in one class.) BTW, what other things besides hyphenation needs to go into user configuration/fo user agent, say for 1.0? Two more observations: 1.) What does the team think of placing all the FOUserAgent information into the abstract apps.InputHandler class by either (a) full incorporation (i.e., getting rid of FOUserAgent and moving everything in it to InputHandler), or (b) including an FOUserAgent instance variable in apps.InputHandler, or (c) having InputHandler extend FOUserAgent? Then, we would just pass InputHandler around instead of FOUserAgent. I mention this because InputHandler includes the file name information already, that is sometimes good to have at various parts of the pipeline (for example, error messages or AWTRenderer, whose refresh capability requires knowing the input source file names.) I'm not sure of the value of this idea, but am just bringing it up for others to comment. 2.) For the fop.image package, and future packages which have a high chance of being used for transcoder or other non-FOP purposes, I'd like us to factor out the FOUserAgent. We had a small problem a few months back when Thomas DeWeese was updating our fop.image package for the transcoder and had trouble trying to figure out how to create an FOUserAgent in order to supply a method parameter. (Turned out only a logger within FOUserAgent was being used, so I changed the method signature to just require that.) More generally, explicitly send in the needed values from FOUserAgent into the called package (eliminating the need for other callees to create an FOUserAgent instance), or, for those packages which require lots of variables in order to be properly initialized, create the collection class (i.e., like a ImageUserAgent) in that package, not in the callee's package. Then *any* callee can just import that collection class, fill it up, and send it back to the called package. Glen
Re: User configuration for hyphenation
Glen Mazza wrote: I don't know what Xalan does with their translets, I suspect they just rely on the caller to implement it. Oops--my error--the translets just generate Java code. My comment was in general for the need of XML processors such as Xalan and FOP to implement MT internally. Glen
Re: User configuration for hyphenation
Glen Mazza wrote: Should FOP itself multithread, or would it be better to let whatever would call FOP do the multithreading? I don't understand this. Even if the main processing methods of the FO processing object are synchronizend, which is probaly what you understand by FOP isn't MT safe itself, the user can create multiple processors and use them concurrently. Mutable static data, like a static logger reference, interferes severely with using FOP in an MT environment, because this means one thread rendering globally rather than one thread per FO processor rendering, perhaps using multiple processors, each one in a separate thread. That's going to raise complaints, check the posts complaining about the global options in the maintenance branch. I'd say we may use static data only in a few cases: - Immutable data, like name mappings and fallback options - Global font and perhaps image caches - Object pools (although they are said to decrease performance for modern JREs) J.Pietschmann
Re: User configuration for hyphenation
Glen Mazza wrote: BTW, what other things besides hyphenation needs to go into user configuration/fo user agent, say for 1.0? Various strategy parameters, once they are implemented, like line breaking strategy; furthermore callbacks for redrawing pages in a GUI renderer, font management, base URL for images etc. J.Pietschmann
Re: User configuration for hyphenation
On 08.05.2004 23:04:40 Simon Pepping wrote: I am trying to enable user configuration of the directory of hyphenation files, like in the maintenance code. Configuration of the renderers is easy, because they are instantiated in Fop.main(). But hyphenation is done deep down in the process, where any reference to the start-up objects is lost. How can I configure it? If I am correct, in the maintenance code the user configuration could be accessed by a static method, anywhere in the process, just like a log file in commons logging. I suppose that is not the preferred way of accessing configuration in HEAD? Indeed. Logging is a special case where static lookup is in order. For the other cases lookup via references is preferred (IMO). This is the stack frame: [1] org.apache.fop.layout.hyphenation.Hyphenator.getHyphenationTree (Hyphenator.java:67) [2] org.apache.fop.layout.hyphenation.Hyphenator.hyphenate (Hyphenator.java:232) [3] org.apache.fop.layoutmgr.LineLayoutManager.getHyphenContext (LineLayoutManager.java:479) [4] org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss (LineLayoutManager.java:228) [5] org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss (BlockLayoutManager.java:204) [6] org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss (FlowLayoutManager.java:79) [7] org.apache.fop.layoutmgr.PageLayoutManager.getNextBreakPoss (PageLayoutManager.java:229) [8] org.apache.fop.layoutmgr.PageLayoutManager.doLayout (PageLayoutManager.java:194) The first two frames are in static context. The LMs share a reference to a user agent object, of type layoutmgr.AbstractLayoutManager.userAgent. Would this be the right object to hold a reference to the user configuration? On first thought, yes. But I feel the scope of the FOUserAgent is still somewhat undefined. Maybe we need to finally settle this issue. Until this is done I consider it safe to hold the user configuration in there. We can change that easily later. Jeremias Maerki
User configuration for hyphenation
Hi, I am trying to enable user configuration of the directory of hyphenation files, like in the maintenance code. Configuration of the renderers is easy, because they are instantiated in Fop.main(). But hyphenation is done deep down in the process, where any reference to the start-up objects is lost. How can I configure it? If I am correct, in the maintenance code the user configuration could be accessed by a static method, anywhere in the process, just like a log file in commons logging. I suppose that is not the preferred way of accessing configuration in HEAD? This is the stack frame: [1] org.apache.fop.layout.hyphenation.Hyphenator.getHyphenationTree (Hyphenator.java:67) [2] org.apache.fop.layout.hyphenation.Hyphenator.hyphenate (Hyphenator.java:232) [3] org.apache.fop.layoutmgr.LineLayoutManager.getHyphenContext (LineLayoutManager.java:479) [4] org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss (LineLayoutManager.java:228) [5] org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss (BlockLayoutManager.java:204) [6] org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss (FlowLayoutManager.java:79) [7] org.apache.fop.layoutmgr.PageLayoutManager.getNextBreakPoss (PageLayoutManager.java:229) [8] org.apache.fop.layoutmgr.PageLayoutManager.doLayout (PageLayoutManager.java:194) The first two frames are in static context. The LMs share a reference to a user agent object, of type layoutmgr.AbstractLayoutManager.userAgent. Would this be the right object to hold a reference to the user configuration? Your advice would be appreciated. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 28431] - [PATCH] Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 [PATCH] Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-26 19:35 --- Luca, I agree with item 1. Although the spaces before the hyphenated word are often incorrect, the word is hyphenated correctly, and the patch solves the problem it set out to solve. I also agree with item 2. The break up of the word is incorrect. Also the spaces before the hyphenated word are often incorrect. However, this problem is not caused by the patch, it is just revealed by it. The patch can be applied. The break-up and spacing problems should be solved in a separate effort. Simon
DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-19 10:30 --- Simon, concernig names, unnecessary if, etc. , I agree with you. It seems to me that your change concerning hyphenation exceptions works, otherwise the hyphenation points would appear in the wrong place because of the punctuation marks. The strange pdf generated is due, IMO, to a couple of problems: -1- In the last test case the text is (quite oddly) divided among 3 TextLM **[...]** (philanthrop ic). Specifying the property linefeed-treatment=ignore, the text is all in a TLM. Removing from the test file the linefeed after (philanthropic)., the text is still split in two parts: *** *** (philanthropic). So, it seems there is an irksome bug affecting text splitting. -2- The last line in a justified paragraph is sometimes justified too (bug 28314). The phantom linefeed is by default treated as a space, and so it is adjusted. Anyway, I was pleased to notice that, although shattered, the word is correctly collected and hyphenated. Regards Luca
Re: [Bug 27773] - [PATCH] Hyphenation
I think it would be better to report this item in a patch of its own. It really is a new issue. Ok, sorry. I'm going to do as you suggest. Luca
DO NOT REPLY [Bug 28431] New: - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28431.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28431
Hyphenation of words with punctuation marks
Summary: Hyphenation of words with punctuation marks
Product: Fop
Version: 1.0dev
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Other
Component: page-master/layout
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have found a small bug concerning hyphenation in the
HyphenationTree.hyphenate() method.
Before checking the exception list or using the algorithm, the
function normalizes the word: during this phase, if a non-letter character
is found null is returned.
// normalize word
char[] c = new char[2];
for (i = 1; i = len; i++) {
c[0] = w[offset + i - 1];
int nc = classmap.find(c, 0);
if (nc 0) {// found a non-letter character, abort
return null;
}
word[i] = (char)nc;
}
I think the condition (nc 0) is too strong: at the moment words followed by
punctuation marks, or in parenthesis, are not hyphenated.
So, for example, the word suggestion can be hyphenated, but suggestion.
and (suggestion), cannot.
This is how I tried to fix this problem:
- non-letter characters at the beginning are not copied into word[]
- if a non-letter character is found which is not at the beginning, it is not
copied into word[] and a boolean variable becomes true
- if a letter-character is found when the variable is true, null is returned;
otherwise, word[] is used to find hyphenation points
I have also added a little optimization: if, after the normalization and the
non-letter character removal, the word size is less than (remainCharCount +
pushCharCount), null is returned, without checking the exception list and
performing the algorithm.
I'm going to attach the proposed patch and a test fo file which shows a few
examples.
Regards
Luca
DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-16 13:29 --- Created an attachment (id=11258) proposed patch to HyphenationTree
DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-16 13:30 --- Created an attachment (id=11259) test fo file: words with punctuation marks and parenthesis
DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-16 19:44 --- Luca, The patch works well. I do not find the name bAfterLetter very clear. It really is bNonLetterAfterLetters, but that is too long. I find bEndOfLetters a reasonable choice. The 'else if (!bAfterLetter)' might as well be just 'else'. The venom is in the tail. I do not know the details of this part of hyphenation. Your addition of 'iIgnoreAtBeginning' seems OK. I think you should also add 'iIgnoreAtBeginning' in the if branch (hyphenation exceptions), but the results of a test fo are not quite in favour. Perhaps you can have a look into this. I added a long comment explaining various features, perhaps most to myself. I added cases to the test fo showing a word that is too short (when one adds debug logging, one sees the effect), and 4 cases with a hyphenation exception word. Regards, Simon
DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-16 19:45 --- Created an attachment (id=11264) An expanded test fo file
DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-16 19:46 --- Created an attachment (id=11265) A slightly modified patch
DO NOT REPLY [Bug 28431] - Hyphenation of words with punctuation marks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28431 Hyphenation of words with punctuation marks --- Additional Comments From [EMAIL PROTECTED] 2004-04-17 05:17 --- Your assumptions appear correct, I checked the Washington Post newspaper and saw that hyphenation does indeed occur with words that have a period or comma at the end of them. Glen
Re: [Bug 27773] - [PATCH] Hyphenation
Luca,
I have noticed this problem, and it is nice to see that you are taking
it on. I think it would be better to report this item in a patch of
its own. It really is a new issue.
Simon
On Wed, Apr 14, 2004 at 07:00:10PM -, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-04-14 19:00 ---
Yes, I was quite surprised to see that all the information stored in the
BreakPoss was thrown away before adding areas; I chose to duplicate the
needed values because this involved fewer and less radical changes.
I have found another small bug concerning hyphenation in the
HyphenationTree.hyphenate() method.
Before checking the exception list or using the algorithm, the
function normalizes the word: during this phase, if a non-letter character
is found null is returned.
// normalize word
char[] c = new char[2];
for (i = 1; i = len; i++) {
c[0] = w[offset + i - 1];
int nc = classmap.find(c, 0);
if (nc 0) {// found a non-letter character, abort
return null;
}
word[i] = (char)nc;
}
I think the condition (nc 0) is too strong: at the moment words followed by
punctuation marks, or in parenthesis, are not hyphenated.
This is how I tried to fix this problem:
- non-letter characters at the beginning are not copied into word[]
- if a non-letter character is found which is not at the beginning, it is not
copied into word[] and a boolean variable becomes true
- if a letter-character is found when the variable is true, null is returned;
otherwise, word[] is used to find hyphenation points
I have also added a little optimization: if, after the normalization and the
non-letter character removal, the word size is less than (remainCharCount +
pushCharCount), null is returned, without checking the exception list and
performing the algorithm.
I'm going to attach the proposed patch and a test fo file which shows a few
examples.
Regards
Luca
--
Simon Pepping
home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773
[PATCH] Hyphenation
--- Additional Comments From [EMAIL PROTECTED] 2004-04-14 19:00 ---
Yes, I was quite surprised to see that all the information stored in the
BreakPoss was thrown away before adding areas; I chose to duplicate the
needed values because this involved fewer and less radical changes.
I have found another small bug concerning hyphenation in the
HyphenationTree.hyphenate() method.
Before checking the exception list or using the algorithm, the
function normalizes the word: during this phase, if a non-letter character
is found null is returned.
// normalize word
char[] c = new char[2];
for (i = 1; i = len; i++) {
c[0] = w[offset + i - 1];
int nc = classmap.find(c, 0);
if (nc 0) {// found a non-letter character, abort
return null;
}
word[i] = (char)nc;
}
I think the condition (nc 0) is too strong: at the moment words followed by
punctuation marks, or in parenthesis, are not hyphenated.
This is how I tried to fix this problem:
- non-letter characters at the beginning are not copied into word[]
- if a non-letter character is found which is not at the beginning, it is not
copied into word[] and a boolean variable becomes true
- if a letter-character is found when the variable is true, null is returned;
otherwise, word[] is used to find hyphenation points
I have also added a little optimization: if, after the normalization and the
non-letter character removal, the word size is less than (remainCharCount +
pushCharCount), null is returned, without checking the exception list and
performing the algorithm.
I'm going to attach the proposed patch and a test fo file which shows a few
examples.
Regards
Luca
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-04-14 19:03 --- Created an attachment (id=11238) test fo file: words with punctuation marks and parenthesis
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773
[PATCH] Hyphenation
--- Additional Comments From [EMAIL PROTECTED] 2004-04-09 09:28 ---
Hi Luca,
Your patch looks good. It works fine on your test fo, and it also
works fine on a test fo I had lying around.
There are a few things to note:
AreaInfo.bHyphenated is identical to (flags BreakPoss.HYPHENATED);
ai.ipdArea = MinOptMax.add(ai.ipdArea, new MinOptMax(hyphIPD)) is
equivalent to bp.setStackingSize(MinOptMax.add(ipd, new
MinOptMax(hyphIPD))). In other words, the same information is present
in the BreakPoss, which is held by the LineLM. Unfortunately, this
information is not accessible in the addAreas method of TextLM. This
is so because posIter.next() returns the position member of the
BreakPoss, not the BreakPoss itself. I believe that is an error in
PositionIterator which eventually needs correction. For now your
solution is a good one.
Your proposed TextInfo.hypChar is also known as
LineLM.hyphProps.hyphenationChar. This information is not passed on to
childLMs and thus not known to TextLM. Storing it in TextInfo seems a
good idea; perhaps it is not even needed in hyphProps.
It is not completely clear that
+if (ai.bHyphenated) {
+str += foText.textInfo.hyphChar;
+ai.ipdArea = MinOptMax.add(ai.ipdArea, new MinOptMax(hyphIPD));
+}
is always correct. This happens on the last AI returned by
posIter.next(), which is not necessarily the last one in the line. But
it is hard to conceive of an AI which is last in its LM and also
hyphenated; therefore it will work. Ideally, the LineLM indicates
which BP is the one ending the line; perhaps this needs correction at
some time.
Regards, Simon
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27773
[PATCH] Hyphenation
--- Additional Comments From [EMAIL PROTECTED] 2004-04-05 09:22 ---
Hi all
I apologize for having posted some proposed changes without a line explaining
what I was changing and why.
Really sorry, I'm going to try and do it now.
First of all, the condition now tested in the
LineLayoutManager.getNextBreakPoss() to decide whether or not to try
hyphenation is:
if (bTextAlignment == TextAlign.JUSTIFY || prevBP == null) {
...
}
So hyphenation is tried for *every* justified block of text; only if
the language attribute is not set the getHyphenContext() method returns null
and hyphenation is not actually done.
My suggestion is to change it so that the fo property hyphenate (7.9.4 in the
recommendation, and already implemented in the CommonHyphenation class) is
tested instead:
if (hyphProps.hyphenate == Constants.TRUE) {
...
}
In the TextInfo class there is a boolean attribute called bCanHyphenate, but
it is given a default value of true, and it is no more modified. It seems to
me that it is quite useless.
Is is used in the TextLayoutManager.getHyphenIPD() method:
if (textArray.length iStopIndex || foText.textInfo.bCanHyphenate == false)
{
...
}
but this method is called only if context.tryHyphenate() is true; with my
suggested change, context.tryHyphenate() returns true only if the fo property
hyphenate is true, and so it is no more necessary to test
foText.textInfo.bCanHyphenate.
The second problem is that the hyphenation character is not shown: to fix this
I added in the AreaInfo class (which stores information about the area that
will be generated) a boolean attribute bHyphenated.
Is is set according to the value of the flags of the corresponding BreakPoss,
and it is tested in the TextLayoutManager.addAreas() method to decide whether
to add the hyphen.
Last (and least): I tried to implement the fo property hyphenation-character
(7.9.5 in the recommendation).
As it applies to blocks, I thought to store it as a character variable in the
TextInfo class, with initial value -.
It is set in the PropertyManager.getTextLayoutProps() method, together with
the other TextInfo attribute.
Is is used to calculate the hyphIPD in the TextLayoutManager constructor, and
in the addAreas method.
Bye
Luca
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 16:40 --- Sorry, I'm here again (hope I am not making too much a mess!) :-) I'm going to attach an updated proposed patch, as I noticed there was an error in the one I posted before. In the TextLayoutManager.addAreas() method, the hyphen size must be added to the total inline progression dimension of the line *before* the adjustment calculation; this involves also moving a few lines of code. Bye Luca
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-04-05 16:41 --- Created an attachment (id=11138) updated diff
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-03-19 11:38 --- Created an attachment (id=10868) patch created using cvs diff
DO NOT REPLY [Bug 27773] - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation --- Additional Comments From [EMAIL PROTECTED] 2004-03-19 11:39 --- Created an attachment (id=10869) FO sample file to test the behavior of fop before and after the patch
DO NOT REPLY [Bug 27773] New: - [PATCH] Hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27773 [PATCH] Hyphenation Summary: [PATCH] Hyphenation Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: Enhancement Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tried to solve a few problems concerning hyphenation: - show the '-' at the end of the hyphenated lines - use the fo:hyphenate property to enable hyphenation, instead of the alignment - specify the hyphenation character using the fo:hyphenation-character property With this simple .fo file it is possible to see that before changes the result is the opposite of what expected: hyphenation is done when it shoud not, and not when it shoud. ?xml version=1.0 encoding=iso-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=simple margin=0.5in fo:region-body margin=1in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simple fo:flow flow-name=xsl-region-body fo:blockThe following block has language=it, hyphenate=false and text-align=justify; it should NOT be hyphenated./fo:block fo:block start-indent=0.2in end-indent=0.2in language=it hyphenate=false text-align=justifyLunghissime parolone esagerevoli costringerebbero sillabazione auspicabilmente: precipitevolissimevolmente transatlantico catastrofico./fo:block fo:blockThe following block has language=it, hyphenate=true and text-align=start; it should be hyphenated./fo:block fo:block start-indent=0.2in end-indent=0.2in language=it hyphenate=true text-align=startLunghissime parolone esagerevoli costringerebbero sillabazione auspicabilmente: precipitevolissimevolmente transatlantico catastrofico./fo:block fo:blockThe following block has language=it, hyphenate=true, text- align=justify and hyphenation-character=_./fo:block fo:block start-indent=0.2in end-indent=0.2in language=it hyphenate=true text-align=justify hyphenation-character=_Lunghissime parolone esagerevoli costringerebbero sillabazione auspicabilmente: precipitevolissimevolmente transatlantico catastrofico./fo:block /fo:flow /fo:page-sequence /fo:root This is the diff: Index: xml-fop/src/java/org/apache/fop/fo/PropertyManager.java === RCS file: /home/cvspublic/xml- fop/src/java/org/apache/fop/fo/PropertyManager.java,v retrieving revision 1.24 diff -w -u -r1.24 PropertyManager.java --- xml-fop/src/java/org/apache/fop/fo/PropertyManager.java 27 Feb 2004 17:57:40 - 1.24 +++ xml-fop/src/java/org/apache/fop/fo/PropertyManager.java 18 Mar 2004 12:43:55 - @@ -494,6 +494,9 @@ textInfo.textTransform = this.propertyList.get(PR_TEXT_TRANSFORM).getEnum(); +textInfo.hyphChar = this.propertyList.get( + PR_HYPHENATION_CHARACTER).getCharacter(); + } return textInfo; } Index: xml-fop/src/java/org/apache/fop/fo/TextInfo.java === RCS file: /home/cvspublic/xml-fop/src/java/org/apache/fop/fo/TextInfo.java,v retrieving revision 1.6 diff -w -u -r1.6 TextInfo.java --- xml-fop/src/java/org/apache/fop/fo/TextInfo.java27 Feb 2004 17:57:40 - 1.6 +++ xml-fop/src/java/org/apache/fop/fo/TextInfo.java18 Mar 2004 12:43:55 - @@ -50,8 +50,8 @@ /** fo:letter-spacing property */ public SpaceVal letterSpacing; -/** can this text be hyphenated? */ -public boolean bCanHyphenate = true; +/* the hyphenation character to be used */ +public char hyphChar = '-'; /** fo:text-decoration property: is text underlined? */ public boolean underlined = false; Index: xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java === RCS file: /home/cvspublic/xml- fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java,v retrieving revision 1.15 diff -w -u -r1.15 LineLayoutManager.java --- xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java18 Mar 2004 00:22:40 - 1.15 +++ xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java18 Mar 2004 12:44:00 - @@ -20,6 +20,7 @@ import org.apache.fop.datatypes.Length; import org.apache.fop.fo.PropertyManager; +import org.apache.fop.fo.Constants; import org.apache.fop.fo.properties.CommonMarginBlock; import org.apache.fop.fo.properties.CommonHyphenation
Re: Hyphenation
Luca Furini wrote: Hi all! I am an italian student of the University of Bologna. I have tried to solve a few problems concerning hyphenation, in particular: - show the '-' at the end of the hyphenated lines - use the fo:hyphenate property to enable hyphenation, instead of the alignment - specify the hyphenation character using the fo:hyphenation-character property Thanks for trying. Unfortunately we need a bit more information for your suggested change to make it to the code base. Most importantly, which version of the code are you trying to fix? Maintenance or HEAD? Secondly, could you please follow the procedure for submitting patches, described here: http://xml.apache.org/fop/dev/index.html#patches Please include sample FO files that demonstrate before and after effects of your changes. Thanks very much, Chris
Implicit grants (FOP hyphenation)
(ccing fop-dev and XML PMC) Last year I've invested hours after hours doing a license audit on the XML FOP project mainly because of problems with the hyphenation pattern files. These files have been converted to XML by FOP contributors but almost all files are coming from TeX software repositories where licenses are diverse or non-existent. Some problems were resolved, more than half of the files removed in the process. For one of the files I have been able to get the original author of the hyphenation pattern file to submit a grant form by fax to the ASF. That grant has never been confirmed although I've pinged Jim twice (in April last year). Following that I gave up hunting for grants. I understand that dealing with this is annoying but it brings up the question about on one side requiring grant forms and on the other side having a good infrastructure not depending on one person alone to handle it all. But that's not the reason I write this. I've done the relicensing on the XML FOP project and was again confronted with our hyphenation files. Two of them now have the ALv2 header because for these two files all legal problems have been dealt with (although we don't have any copyright grants on file for them. See big question below). The other files carry copyright statements (or just a file history with names) but appear to be distributable by the ASF. I still have to figure out what to do with them. Most of them appear to be in the public domain (although this is usually not explicitly state as such) so I will probably simply add the ALv2 header if nobody sees any reason why I couldn't do so. I'm real tired of the problem. My big question: The ALv2 specifies implicit grants, right? (Section 5) Can I apply this section to contributions done before the ALv2 was here? Example: For the file (da.xml, Dansk hyphenation patterns, currently not in CVS) mentioned above, I know that a grant was sent to the ASF by the original author of the file (although there's no confirmation of the receipt). And the person who converted the file to XML intentionally submitted it to the FOP mailing list for inclusion in the project. It would appear that I am now able add the ALv2 header to the file and add it to CVS again. Any reason I can't do that? As a related question: The implicit grant works for original works only. Derived works still need a written permission by the original author(s). I'd imagine a written permission is enough. No grant form necessary. Correct? But then, where's the border between not needing a grant and needing one (for example for the new projects coming to the ASF)? Just wondering. A slightly out-of-date log of the FOP audit is here: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003 I apologize if this post may carry a somewhat bitter undertone. It took a lot of time already and I'm still not finished. I wanted to do it right but that's very difficult. So thanks in advance for any insight and good ideas. Jeremias Maerki FOP committer, XML PMC representative for FOP
Re: Implicit grants (FOP hyphenation)
Jeremias Maerki wrote: But that's not the reason I write this. I've done the relicensing on the XML FOP project and was again confronted with our hyphenation files. Two of them now have the ALv2 header because for these two files all legal problems have been dealt with I don't think it is necessary to put *all* files under APL. If we can assume the content had been granted, and there is no infformation to the contrary and no incompatible license already in the file, we can just leave it as it is, or perhaps add something to the effect ... has been contributed to FOP and is assumed to be licensed for all purposes FOP can be used. Contact the authors stated above for further details. (unless license@ says otherwise, of course) Tracking down the original committer from CVS might help too, but in general I wouldn't loose much further sleep on the whole issue. Of course, newly contributed files should be put under APL which means all issues have to be resolved before the file is committed to CVS. J.Pietschmann
Re: Implicit grants (FOP hyphenation)
I agree. But if we don't put them under the ALv2 we need to clearly mark the files as such. Like we do for the JARs in the lib directory. But before we do anything I'd like to see if there's any answer to my questions. On 05.03.2004 21:29:39 J.Pietschmann wrote: Jeremias Maerki wrote: But that's not the reason I write this. I've done the relicensing on the XML FOP project and was again confronted with our hyphenation files. Two of them now have the ALv2 header because for these two files all legal problems have been dealt with I don't think it is necessary to put *all* files under APL. If we can assume the content had been granted, and there is no infformation to the contrary and no incompatible license already in the file, we can just leave it as it is, or perhaps add something to the effect ... has been contributed to FOP and is assumed to be licensed for all purposes FOP can be used. Contact the authors stated above for further details. (unless license@ says otherwise, of course) Tracking down the original committer from CVS might help too, but in general I wouldn't loose much further sleep on the whole issue. Of course, newly contributed files should be put under APL which means all issues have to be resolved before the file is committed to CVS. Jeremias Maerki
cvs commit: xml-fop/src/java/org/apache/fop/layout/hyphenation ByteVector.java CharVector.java Hyphen.java Hyphenation.java HyphenationException.java HyphenationTree.java Hyphenator.java PatternConsumer.java PatternParser.java TernaryTree.java
jeremias2004/02/27 09:48:09 Modified:src/java/org/apache/fop/layout/hyphenation ByteVector.java CharVector.java Hyphen.java Hyphenation.java HyphenationException.java HyphenationTree.java Hyphenator.java PatternConsumer.java PatternParser.java TernaryTree.java Log: Applied Apache License Version 2.0 by following the instructions at http://www.apache.org/dev/apply-license.html. Revision ChangesPath 1.2 +16 -48 xml-fop/src/java/org/apache/fop/layout/hyphenation/ByteVector.java Index: ByteVector.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layout/hyphenation/ByteVector.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ByteVector.java 11 Mar 2003 13:05:33 - 1.1 +++ ByteVector.java 27 Feb 2004 17:48:08 - 1.2 @@ -1,53 +1,21 @@ /* - * $Id$ - * - *The Apache Software License, Version 1.1 - * + * Copyright 1999-2004 The Apache Software Foundation. * - * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without modifica- - * tion, are permitted provided that the following conditions are met: - * - * 1. Redistributions of source code must retain the above copyright notice, - *this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright notice, - *this list of conditions and the following disclaimer in the documentation - *and/or other materials provided with the distribution. - * - * 3. The end-user documentation included with the redistribution, if any, must - *include the following acknowledgment: This product includes software - *developed by the Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgment may appear in the software itself, if - *and wherever such third-party acknowledgments normally appear. - * - * 4. The names FOP and Apache Software Foundation must not be used to - *endorse or promote products derived from this software without prior - *written permission. For written permission, please contact - *[EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache, nor may - *Apache appear in their name, without prior written permission of the - *Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * - * This software consists of voluntary contributions made by many individuals - * on behalf of the Apache Software Foundation and was originally created by - * James Tauber [EMAIL PROTECTED]. For more information on the Apache - * Software Foundation, please see http://www.apache.org/. - */ + * Licensed 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.layout.hyphenation; import java.io.Serializable; 1.2 +16 -48 xml-fop/src/java/org/apache/fop/layout/hyphenation/CharVector.java Index: CharVector.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layout/hyphenation
cvs commit: xml-fop/src/java/org/apache/fop/layout/hyphenation HyphenationTree.java
pbwest 2004/01/02 04:18:45
Modified:src/java/org/apache/fop/layoutmgr PageLayoutManager.java
src/java/org/apache/fop/pdf PDFEncryptionJCE.java
src/java/org/apache/fop/render/pdf PDFRenderer.java
src/java/org/apache/fop/image FopImageConsumer.java
src/java/org/apache/fop/layout/hyphenation
HyphenationTree.java
Log:
Removed unnecessary semi-colon.
Revision ChangesPath
1.27 +1 -1 xml-fop/src/java/org/apache/fop/layoutmgr/PageLayoutManager.java
Index: PageLayoutManager.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/PageLayoutManager.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- PageLayoutManager.java29 Dec 2003 23:28:47 - 1.26
+++ PageLayoutManager.java2 Jan 2004 12:18:44 - 1.27
@@ -401,7 +401,7 @@
if (childArea.getAreaClass() == Area.CLASS_NORMAL) {
placeFlowRefArea(childArea);
} else {
-; // todo: all the others!
+ // todo: all the others!
}
}
1.3 +1 -1 xml-fop/src/java/org/apache/fop/pdf/PDFEncryptionJCE.java
Index: PDFEncryptionJCE.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/pdf/PDFEncryptionJCE.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- PDFEncryptionJCE.java 27 Mar 2003 11:10:33 - 1.2
+++ PDFEncryptionJCE.java 2 Jan 2004 12:18:45 - 1.3
@@ -414,7 +414,7 @@
hash[i++] = (byte) (number 8);
hash[i++] = (byte) (number 16);
hash[i++] = (byte) (generation 0);
-hash[i++] = (byte) (generation 8);;
+hash[i++] = (byte) (generation 8);
return hash;
}
1.26 +1 -1 xml-fop/src/java/org/apache/fop/render/pdf/PDFRenderer.java
Index: PDFRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/pdf/PDFRenderer.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- PDFRenderer.java 12 Dec 2003 22:37:39 - 1.25
+++ PDFRenderer.java 2 Jan 2004 12:18:45 - 1.26
@@ -1245,7 +1245,7 @@
endTextObject();
if (viewport.getClip()) {
-saveGraphicsState();;
+saveGraphicsState();
clip(x, y, width, height);
}
1.2 +1 -1 xml-fop/src/java/org/apache/fop/image/FopImageConsumer.java
Index: FopImageConsumer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/image/FopImageConsumer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FopImageConsumer.java 11 Mar 2003 13:05:25 - 1.1
+++ FopImageConsumer.java 2 Jan 2004 12:18:45 - 1.2
@@ -55,7 +55,7 @@
import java.awt.image.ColorModel;
import java.awt.image.ImageConsumer;
import java.awt.image.ImageProducer;
-import java.awt.image.PixelGrabber;;
+import java.awt.image.PixelGrabber;
/**
* ImageConsumer implementation for FopImage classes.
1.2 +0 -1
xml-fop/src/java/org/apache/fop/layout/hyphenation/HyphenationTree.java
Index: HyphenationTree.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/layout/hyphenation/HyphenationTree.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HyphenationTree.java 11 Mar 2003 13:05:33 - 1.1
+++ HyphenationTree.java 2 Jan 2004 12:18:45 - 1.2
@@ -530,7 +530,6 @@
token = in.readLine().trim();
long starttime = 0;
int counter = 0;
-;
try {
BufferedReader reader =
new BufferedReader(new FileReader(token));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13734] - Hyphenation does not work correctly on long string with many '-'
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13734. 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=13734 Hyphenation does not work correctly on long string with many '-' --- Additional Comments From [EMAIL PROTECTED] 2003-12-21 18:58 --- The first case works OK in the development version. See attachment. The behaviour of the second case is to be expected, because there is no possible breakpoint. ',' is not a possible breakpoint. See attachment. How is case 3 different from case 2?
DO NOT REPLY [Bug 16713] - Hyphenation error in tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16713. 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=16713 Hyphenation error in tables --- Additional Comments From [EMAIL PROTECTED] 2003-12-21 19:01 --- The attachments require other files which are not attached: three xsl files and an external graphic.
DO NOT REPLY [Bug 21641] - Infinit loop within too small areas using hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21641. 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=21641 Infinit loop within too small areas using hyphenation --- Additional Comments From [EMAIL PROTECTED] 2003-12-21 19:01 --- OK in the development version.
DO NOT REPLY [Bug 16626] - Hyphenation causing java.io.IOException error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16626. 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=16626 Hyphenation causing java.io.IOException error [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-12-15 22:41 --- We will not get this fixed for the maintenance branch, however a fix on this problem was applied to development so this should not occur in our next release. Thanks, Glen *** This bug has been marked as a duplicate of 25512 ***
DO NOT REPLY [Bug 23985] - Hyphenation Problems with filenames, numbers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23985. 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=23985 Hyphenation Problems with filenames, numbers [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 05:52 --- Fixed in 1.0. Due to maintenance code complexity vs. benefit gained, I will skip making the changes in 0.20.x. (Also, I could not duplicate the problem in the nightly version of maintenance using Acrobat Reader 6.0, as I could in the release version w/AR 5.5. So other factors may make this issue less likely to occur with 0.20.5 anyway.)
DO NOT REPLY [Bug 22048] New: - PDF renderer and hyphenation break character order
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22048. 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=22048 PDF renderer and hyphenation break character order Summary: PDF renderer and hyphenation break character order Product: Fop Version: 0.20.4 Platform: PC URL: http://staff.csc.fi/aniemela/fopbug2.pdf OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The PDF renderer/page layout component/hyphenation break character order with inline elements: The following construct fo:block Otsakerivin vapaamuotoisuuden takia ainoat jarkevasti hyodynnettavat arvot ovat kentan nimi ( fo:inline font-family=monospacelt;melting.pointgt;/fo:inline ) ja DT-numero. /fo:block Is rendered as Otsakerivin [] hyodynnettavat arvot ovat kentan nimi ( mel- ting.point ) ja DT-numero. Below is a cleaned-up version of Docbook-XSLT-produced FO data, which explains the block-happiness. URL points to a FOP 0.20.4 rendered PDF which illustrates the bug. Full XSL-FO data follows: ?xml version=1.0 encoding=utf-8 ? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif font-size=10pt text-align=left line-height=normal font-selection-strategy=character-by-character language=en fo:layout-master-set fo:simple-page-master master-name=blank page-width=210mm page-height=297mm margin-top=0.5in margin-bottom=0.5in margin-left=1in margin-right=1in fo:region-body display-align=center margin-bottom=0.5in margin-top=0.5in region-name=blank-body / /fo:simple-page-master fo:simple-page-master master-name=body-first page-width=210mm page-height=297mm margin-top=0.5in margin-bottom=0.5in margin-left=1in margin-right=1in fo:region-body margin-bottom=0.5in margin-top=0.5in column-count=1 / /fo:simple-page-master fo:simple-page-master master-name=body-odd page-width=210mm page-height=297mm margin-top=0.5in margin-bottom=0.5in margin-left=1in margin-right=1in fo:region-body margin-bottom=0.5in margin-top=0.5in column-count=1 / /fo:simple-page-master fo:simple-page-master master-name=body-even page-width=210mm page-height=297mm margin-top=0.5in margin-bottom=0.5in margin-right=1in margin-left=1in fo:region-body margin-bottom=0.5in margin-top=0.5in column-count=1 / /fo:simple-page-master fo:page-sequence-master master-name=body fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=blank blank-or-not-blank=blank / fo:conditional-page-master-reference master-reference=body-first page-position=first / fo:conditional-page-master-reference master-reference=body-odd odd-or-even=odd / fo:conditional-page-master-reference master-reference=body-even odd-or-even=even / /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence xmlns:axf=http://www.antennahouse.com/names/XSL/Extensions; hyphenate=true master-reference=body language=fi format=1 initial-page-number=1 hyphenation-character=- hyphenation-push-character-count=2 hyphenation-remain-character-count=2 fo:flow flow-name=xsl-region-body fo:block id=d0e14 fo:block fo:block fo:block keep-together=always margin-left=-4pc font-family=sans-serif fo:block keep-with-next.within-column=always fo:block font-family=sans-serif font-weight=bold keep-with-next.within-column=always space-before.minimum=0.8em space-before.optimum=1.0em space-before.maximum=1.2em fo:block font-size=14.399pt1.1.1. Datamerkinnan otsakerivi/fo:block /fo:block /fo:block /fo:block /fo:block fo:block / /fo:block fo:block space-before.optimum=1em space-before.minimum=0.8em space-before.maximum=1.2em Otsakerivin vapaamuotoisuuden takia ainoat jarkevasti hyodynnettavat arvot ovat kentan nimi ( fo:inline font-family=monospacelt;melting.pointgt;/fo:inline ) ja DT-numero. /fo:block /fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22048] - PDF renderer and hyphenation break character order
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22048. 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=22048 PDF renderer and hyphenation break character order [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-01 12:40 --- This has been fixed already. Get the latest release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21641] New: - Infinit loop within too small areas using hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21641. 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=21641 Infinit loop within too small areas using hyphenation Summary: Infinit loop within too small areas using hyphenation Product: Fop Version: 0.20.5 Platform: PC OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Using hyphenate=true rendering text within a too small area (e.g. a small table column) results in an inifite loop. The loop appeares in FOText.java line 280 (while ( start != -1)) which never ends, because LineAread.addText(...) never returns -1. I think The bug should be fixed in LineAread.addText(...). Example document: ?xml version=1.0 encoding=utf-8 standalone=yes? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin=2cm master-name=simple page-height=29.7cm page-width=21cm fo:region-body/ fo:region-before extent=3cm/ fo:region-after extent=1.5cm/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simple hyphenate=true language=en fo:flow flow-name=xsl-region-body fo:table table-layout=fixed fo:table-column column-width=4mm/ fo:table-body fo:table-row fo:table-cell border-color=black border-style=solid border-width=thin fo:block font-size=8pt font-family=Times margin=1mmverylongword/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21641] - Infinit loop within too small areas using hyphenation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21641. 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=21641 Infinit loop within too small areas using hyphenation [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Normal --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 17:40 --- Well, doing unpleasant things on invalid input isn't really a critical bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
hyphenation doc has moved
I did some rearranging in our doc to get the configuration page pared down to only configuration information, and to move some configuration content there that was lurking in other places (attempting to keep them cross-referenced). One of the side effects is that the hyphenation doc has been moved out of configuration and into its own document, which has an entry on the menu. FYI in case you can't find it where you are used to finding it. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Status update: hyphenation (no, not the pattern file licenses)
Jeremias Maerki wrote: Well, separate the reusable stuff from the FOP-specific stuff (package-wise). Other Apache projects have started sub-(sub-)projects. Maybe we could do something similar if only to encourage decoupling of utility components that could be used elsewhere. Additional candidates: PDF library, Transcoders, a free image library etc. etc. Humm. Unfortunately I don't see how we get the manpower to manage subsubprojects and attract developers. I'd rather think of asking jakarta-commons-lang or the sandbox. Another question: How does your work relate to the general possibility to make use of OpenOffice.org's hyphenation stuff. Umm, zilch. But then, th OOo hyphenation files I saw are just the FOP hyphenation files sans XML tags and with character encoding issues instead. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Status update: hyphenation (no, not the pattern file licenses)
Hi, as I wrote quite some weeks ago I took an extended look at hyphenation, with the possible target of creating APL licensed patterns from our own dictionaries. I also looked at the current hyphenator. I finally seem to have grasped how hyphenation and hyphenation pattern generation from a marked up dictionary (patgen.web) works. I implemented my own qd hyphenator which lead to the detection of a few well hidden bugs in the current hyphenator. Interestingly, nobody seems to care all that much. Do people proof read their output? Other problems with the current hyphenator are that it contains a lot of crufty code, has a few easy to cure inefficiencies, and it can't handle hyphenations with consonant shifts and other spelling changes, like in the old german spelling backen - bak-ken and Schiffahrt - Schiff-fahrt, despite it seems to claim so. (the new german spelling does no longer have these features, but I think there are still languages where this is an issue). Furthermore, the interaction between the main code and the hyphenator is somewhat ineffective too, and the main code does not necessarily have the same understanding on what consitutes a word than the hyphenator. In parallel to working on the unit test concept and preparing for some refactoring in HEAD, I'm working now on providing a patgen.web rewrite in Java which does not have some of the restricting features of the original and also on a german lexicon which has currently roughly 12k stem forms of words with hyphenation and other information. Help with comleting the lexicon or with other languages is welcome. Unfortunately tools for lexicon maintenance, word inflection and plausibility checks on hyphenated forms are still alpha, at best. I'll publish them on my Apache home page in a few days. RT: I believe the lexicon(s), pattern generator, the hyphenator and perhaps other tools could be useful for other projects. What would be a sensible approach to encourage reuse? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Status update: hyphenation (no, not the pattern file licenses)
On 04.07.2003 22:59:27 J.Pietschmann wrote: Interestingly, nobody seems to care all that much. Do people proof read their output? LOL snip what=a lot of interesting-sounding stuff/ RT: I believe the lexicon(s), pattern generator, the hyphenator and perhaps other tools could be useful for other projects. What would be a sensible approach to encourage reuse? Well, separate the reusable stuff from the FOP-specific stuff (package-wise). Other Apache projects have started sub-(sub-)projects. Maybe we could do something similar if only to encourage decoupling of utility components that could be used elsewhere. Additional candidates: PDF library, Transcoders, a free image library etc. etc. Another question: How does your work relate to the general possibility to make use of OpenOffice.org's hyphenation stuff. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20411] - German hyphenation is ^H^H^Hwas missing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20411. 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=20411 German hyphenation is ^H^H^Hwas missing [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-06-02 13:20 --- We've had german hyphenation files in FOP earlier but had to remove them because of license issues. See Release Notes (http://xml.apache.org/fop/relnotes.html). Unfortunately, your hyphenation file is based on a file released under the LPPL which is considered incompatible with the ASL. Therefore, we can't accept your contribution. I'm sorry. I've recently updated the documentation on this topic (http://xml.apache.org/fop/configuration.html). If the LPPL works for your environment, fine. You can even publish the file yourself as long as you respect the license of the original file. But Apache can't redistribute that file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20411] New: - German hyphenation is ^H^H^Hwas missing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20411. 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=20411 German hyphenation is ^H^H^Hwas missing Summary: German hyphenation is ^H^H^Hwas missing Product: Fop Version: 0.20.5 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have converted a TeX hyphenation file. The conversion was done by Perl, by vi and by hand, be prepared for errors. I have tested it with a document of 50 pages, and haven't found any obvious bugs, however. The file is (hopefully) attached to the bug report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20411] - German hyphenation is ^H^H^Hwas missing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20411. 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=20411 German hyphenation is ^H^H^Hwas missing --- Additional Comments From [EMAIL PROTECTED] 2003-06-02 11:08 --- Created an attachment (id=6595) Hyphenation file for (new) German orthography - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Hyphenation: new russian hyphenation patterns added
With the kind help of Alex V. Alishevskikh I've been able to commit a new pattern file for russian. The file should be pretty safe from a legal point of view. Interested parties will find the details in the comments provided in ru.xml. Yipee! :-) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML FOP: Licensing issues with hyphenation pattern files
Before we start here's a little background on the hyphenation stuff:
Our hyphenation file are XML files that are derived from TeX hyphenation
Under what license where the original TeX files ?
2. If the former (of [1]) is true, we need a grant from the copyright
holder of the original file, right? What if the original file is unclear
This depends on what the license was you got it under.
If there is no (explicit) license; you'll have to indeed get permission of
the authors as the default generally is 'No' (depending on age of the
file and country).
3. (Question is somewhat general) What's the threshold for the necessity
of a grant? Does a non-committer have to submit a grant on a single new
file?
If code written by someone else under a non-apache license is imported; it
will need to a grant to become part of the apache proper (as to allow us
to remove the original and cut-and-paste the asf license into it).
OR
it needs to be labeled as NOT apache; and have the right license next to
it. See for example in cvs
apache-1.3/src/regex
apache-1.3/src/regex/COPYRIGHT
Also note that it is in its own directory.
4. Some of the hyphenation pattern files are licensed under the LPPL
(LaTeX project public license, http://www.latex-project.org/lppl.html).
We'd like to have clearance to use, modify and distribute files under
this license in the FOP project.
Ack - will post on that in a moment.
5. Can we modify and relicense under the ASL hyphenation pattern files
clearly stated as being in the public domain without having a grant but
Propably - but depending on what country that('this is public domain') was
'stated' in and at what day; as the Berne convention was not signed by all
countries at the same time. (The Berne convention effectively killed the
concept of 'Public Domain' or -non- copyrighted material in most
countries - and makes the statement 'this is public domain' somethings
ineffective if not backed up by a license, grant and/or copyright.).
6. We can't use files containing a restriction like Can be used freely
for non-commercial purposes., except if we can positively identify the
copyright holder and get a grant, right?
Correct - as that would mean that you can download something from
apache.org which has _MORE_ restrictive elements in it than the ASF
license. Anything we include under 3rd party licenses should be as
restrictive or -less- restrictive than our own license. So that when you
download something from *.apache.org it can always be used in with the ASF
level of freedom; and perhaps some bits may give you even -more- leeway.
Never less.
Dw
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: XML FOP: Licensing issues with hyphenation pattern files
Folks, See below the Latex License. http://www.latex-project.org/lppl.html It seems to me that clause '8.B makes this license more restrictive than the ASF license - and we thus should not allow code(fragements) which are under this license in downloads from ASF infrastructure. Or am I misreading things - the license is long and weildy. Dw LaTeX Project Public License LPPL Version 1.2 1999-09-03 Copyright 1999 LaTeX 3 Project Everyone is allowed to distribute verbatim copies of this license document, but modification of it is not allowed. PREAMBLE The LaTeX Project Public License (LPPL) is the license under which the base LaTeX distribution is distributed. You may use this license for any program that you have written and wish to distribute. This license may be particularly suitable if your program is TeX -related (such as a LaTeX package), but you may use it even if your program is unrelated to TeX . The section `WHETHER AND HOW TO DISTRIBUTE PROGRAMS UNDER THIS LICENSE', below, gives instructions, examples, and recommendations for authors who are considering distributing their programs under this license. In this license document, `The Program' refers to any program distributed under this license. This license gives conditions under which The Program may be distributed and conditions under which modified versions of The Program may be distributed. Individual files of The Program may bear supplementary and/or superseding conditions on modification of themselves and on the distribution of modified versions of themselves, but *no* file of The Program may bear supplementary or superseding conditions on the distribution of an unmodified copy of the file. A distributor wishing to distribute a complete, unmodified copy of The Program therefore needs to check the conditions only in this license and nowhere else. Activities other than distribution and/or modification of The Program are not covered by this license; they are outside its scope. In particular, the act of running The Program is not restricted. We, the LaTeX 3 Project, believe that the conditions below give you the freedom to make and distribute modified versions of The Program that conform with whatever technical specifications you wish while maintaining the availability, integrity, and reliability of The Program. If you do not see how to achieve your goal while meeting these conditions, then read the document `cfgguide.tex' in the base LaTeX distribution for suggestions. CONDITIONS ON DISTRIBUTION AND MODIFICATION You may distribute a complete, unmodified copy of The Program. Distribution of only part of The Program is not allowed. You may not modify in any way a file of The Program that bears a legal notice forbidding modification of that file. You may distribute a modified file of The Program if, and only if, the following eight conditions are met: You must meet any additional conditions borne by the file on the distribution of a modified version of the file as described below in the subsection `Additional Conditions on Individual Files of The Program'. If the file is a LaTeX software file, then you must meet any applicable additional conditions on the distribution of a modified version of the file that are described below in the subsection `Additional Conditions on LaTeX Software Files'. You must not distribute the modified file with the filename of the original file. In the modified file, you must acknowledge the authorship and name of the original file, and the name (if any) of the program which contains it. You must change any identification string in the file to indicate clearly that the modified file is not part of The Program. You must change any addresses in the modified file for the reporting of errors in the file or in The Program generally to ensure that reports for files no longer maintained by the original maintainers will be directed to the maintainers of the modified files. You must distribute the modified file under a license that forbids distribution both of the modified file and of any files derived from the modified file with the filename of the original file. You must do either (A) or (B): (A) distribute a copy of The Program (that is, a complete, unmodified copy of The Program) together with the modified file; if your distribution of the modified file is made by offering access to copy the modified file from a designated place, then offering equivalent access to copy The Program from the same place meets this condition, even though third parties are not compelled to copy The Program along with the modified file; (B) provide to those who receive the modified file information that is sufficient for them to obtain a copy of The Program; for example, you may provide a Uniform Resource Locator (URL) for a site that you expect will provide them with a copy of The Program free of charge
Re: XML FOP: Licensing issues with hyphenation pattern files
Thanks, Steven and Dirk for responding!
On 17.03.2003 14:28:44 Dirk-Willem van Gulik wrote:
Before we start here's a little background on the hyphenation stuff:
Our hyphenation file are XML files that are derived from TeX hyphenation
Under what license where the original TeX files ?
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/hyph/
Under many different licenses (GPL, LGPL, LPPL, public domain, no
license...) That's what makes this clean-up work such a PITA.
And then there's the files from the original TeX distribution by Donald
Knuth which are assumed to be in the public domain but with certain
restrictions (modified file shall not contain the same filename as the
original). Problem there is that there is not really something you could
call a license associated with the distribution, at least non that I
could find. This is all more or less based on common knowledge, rather
than hard facts on file.
2. If the former (of [1]) is true, we need a grant from the copyright
holder of the original file, right? What if the original file is unclear
This depends on what the license was you got it under.
If there is no (explicit) license; you'll have to indeed get permission of
the authors as the default generally is 'No' (depending on age of the
file and country).
Ok
3. (Question is somewhat general) What's the threshold for the necessity
of a grant? Does a non-committer have to submit a grant on a single new
file?
If code written by someone else under a non-apache license is imported; it
will need to a grant to become part of the apache proper (as to allow us
to remove the original and cut-and-paste the asf license into it).
That's pretty clear. I was rather thinking about people sending a new
source file to a mailing list of an Apache project. If a grant is
necessary for each and every new file that is submitted, we're going to
scare away potential contributors. From reading the mails about the new
license 2.0 this seems to be adressed there. Anyway, I get the
impression no grant is filed in most cases in most projects at Apache
today. Or do I misunderstand?
I've received an email a few minutes ago from a FOP contributor telling
me that I will receive a confirmation mail from the original author of
one of the problematic hyphenation files, that he allows us to use his
file. But strictly following the rules I have to ask him to file a grant.
I hope he won't mind.
OR
it needs to be labeled as NOT apache; and have the right license next to
it. See for example in cvs
apache-1.3/src/regex
apache-1.3/src/regex/COPYRIGHT
Also note that it is in its own directory.
Is that necessary? Isn't putting an xy.xml.LICENSE file alongside an
xy.xml file enough to mark it as NOT Apache?
snip/
5. Can we modify and relicense under the ASL hyphenation pattern files
clearly stated as being in the public domain without having a grant but
Propably - but depending on what country that('this is public domain') was
'stated' in and at what day; as the Berne convention was not signed by all
countries at the same time. (The Berne convention effectively killed the
concept of 'Public Domain' or -non- copyrighted material in most
countries - and makes the statement 'this is public domain' somethings
ineffective if not backed up by a license, grant and/or copyright.).
Aargh! The world would be so boring if everything were simple. :-)
snip/
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: XML FOP: Licensing issues with hyphenation pattern files
There's another IMO: Clause 7 expects a restriction that the ASL can't provide. On 17.03.2003 14:32:16 Dirk-Willem van Gulik wrote: See below the Latex License. http://www.latex-project.org/lppl.html It seems to me that clause '8.B makes this license more restrictive than the ASF license - and we thus should not allow code(fragements) which are under this license in downloads from ASF infrastructure. Or am I misreading things - the license is long and weildy. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML FOP: Licensing issues with hyphenation pattern files
I've just received that email. The original author is willing to fax in a grant. Question now: Where can I find the form? I've only found the one for committers. Thanks a lot! On 17.03.2003 15:23:55 Jeremias Maerki wrote: I've received an email a few minutes ago from a FOP contributor telling me that I will receive a confirmation mail from the original author of one of the problematic hyphenation files, that he allows us to use his file. But strictly following the rules I have to ask him to file a grant. I hope he won't mind. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: XML FOP: Licensing issues with hyphenation pattern files
Jeremias Maerki wrote: And then there's the files from the original TeX distribution by Donald Knuth which are assumed to be in the public domain but with certain restrictions (modified file shall not contain the same filename as the original). Problem there is that there is not really something you could call a license associated with the distribution, at least non that I could find. This is all more or less based on common knowledge, rather than hard facts on file. Here are some excerpts from Chapter 30, The Future of TeX and METAFONT from Knuth's Digital Typography, 1999, Center for the Study of Language and Information, ISBN 1-57589-010-4: ---Start--- My work on developing TeX, METAFONT, and Computer Modern has come to an end. I will make no further changes except to correct extremely serious bugs. I have put these systems into the public domain so that people everywhere can use the ideas freely if they wish As stated on the copyright pages of Volumes B, D, and E, [referring here to the 5-volume Computers and Typesetting series] anybody can make use of my programs in whatever way they wish, as long as they do not use the names TeX, METAFONT, or Computer Modern. In particular, any person or group who wants to produce a program superior to mine is free to do so. However, nobody is allowed to call a system TeX or METAFONT unless that system conforms 100% to my own programs, as I have specified in the manuals for the TRIP and TRAP tests Of course I do not claim to have found the best solution to every problem. I simply claim that it is a great advantage to have a fixed point as a building block I welcome continued research that will lead to alternative systems that can typeset documents better than TeX is able to do. But the authors of such systems must think of another name ---End--- BTW, nothing in the excised portions of the above are contradictory, only explanatory. The copyright page for Volume B of Computers and Typesetting, which volume is entitled TeX: The Program says the following: The program for TeX is in the public domain, and readers my freely incorporate the algorithms of this book into their own programs. However, use of the name 'TeX' is restricted to software systems that agree exactly with the program presented here. Now, I suppose that an argument could be made that the hyphenation patterns are not part of the algorithm, but I think an equally good argument can be made that they are. They are certainly part of the TeX distribution, and Knuth's license documented above extends to the frozen version of TeX. If the name is TeX, and the files are a part of it, Knuth's license applies. I appreciate the concern for IP rights, and the desire to be conservative on such matters. I am extremely conservative about such things myself, having made my living off of such rights for years. I just don't know what Knuth could have done to be more clear that these files are in the public domain. I suppose a file in the distribution would have been nice, but ... Actually, there might be one, but I haven't been able to find it either. I think the correct solution here is to install the TeX (not LaTeX) hyphenation pattern files, credit Knuth, make a comment that Knuth's files are in the public domain, add the Apache License (to apply to any additions), and turn our users loose looking for things that might need to be added. A post to the user mailing list and a release note (saying that the hyphenation files are different, and perhaps less comprehensive) would be good also. BTW, I don't see a restriction on the /file/ names being the same, only on the product itself being the same. I apologize that some of the above is redundant from previous postings. I did not cite the authorities previously, and perhaps that will help us get moving here again. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML FOP: Licensing issues with hyphenation pattern files
Thanks, Greg and Nicola, for your answers. I've already sent the form to the person I mentioned. Now that most of my questions have been resolved I'm off to distribute quite a bunch of these forms to all the various copyright holders. After it has been suggested that every single file submitted by a non-committer must be accompanied by a license grant it would really make sense to publish the form somewhere under http://www.apache.org/dev/, for example. That's one step towards making all committers aware that these steps should be followed. Maybe this process could be described on a separate page with just a few sentences. It should also be mentioned that the above also applies if a file with someone else's name has been modified and included in a project codebase as is the case with FOP's hypenation patterns. I'm going to document all the findings from this thread within the next two or three days at http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing. Help is welcome. I hope someone with write access will then transfer some of the contents to the Development Information pages. Thanks again to all who have helped resolve our licensing issues so far. On 17.03.2003 21:00:50 Greg Stein wrote: On Mon, Mar 17, 2003 at 04:17:12PM +0100, Jeremias Maerki wrote: I've just received that email. The original author is willing to fax in a grant. Question now: Where can I find the form? I've only found the one for committers. Thanks a lot! On 17.03.2003 15:23:55 Jeremias Maerki wrote: I've received an email a few minutes ago from a FOP contributor telling me that I will receive a confirmation mail from the original author of one of the problematic hyphenation files, that he allows us to use his file. But strictly following the rules I have to ask him to file a grant. I hope he won't mind. I've attached(*) the software grant form which they can print, sign, and fax into the ASF (+1-410-803-2258) or mail to: The Apache Software Foundation 1901 Munsey Drive Forest Hill, MD 21050-2747, U.S.A. (*) no, I don't know where it might be publicly accessible; this is from our Foundation CVS repos Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML FOP: Licensing issues with hyphenation pattern files
I haven't received any reactions to my post. We still have our pending release on hold until the issues are resolved. I wonder if I have taken the wrong approach. Can anybody advise? Thanks! On 06.03.2003 11:10:28 Jeremias Maerki wrote: Hello all (licensing specialists, XML PMC people, fop-devs) (I don't know where might be the best place to discuss this. fop-dev is currently very low-traffic.) The FOP team needs help. In February we realized that we had problematic hyphenation pattern files in our codebase. For example, some of them were derived from GPL-licensed files. Some action has already been taken. I've documented the whole auditing process and status here: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003 I'm at a point where I need some advice on how to proceed from here. Here are the questions, I hope are the right ones and help us to resolve these issues quickly. Before we start here's a little background on the hyphenation stuff: Our hyphenation file are XML files that are derived from TeX hyphenation files (ASCII format). These XML files reside in CVS (xml-fop/src/hyph, formerly xml-fop/hyph). During build they are parsed into Java objects and serialized using Java serialization. These serialized objects are included in the JAR (fop.jar) in the binary distribution. 1. Do our hyphenation files have to be licensed under the ASL? Or is it possible to do something similar we do with Java libraries (external dependencies) such as JUnit and JDOM (add the file to CVS and have an accompanying file containing its license)? 2. If the former (of [1]) is true, we need a grant from the copyright holder of the original file, right? What if the original file is unclear about the copyright holder (multiple names, for example) and about the license (no explicit license, for example)? Please see the Wiki page for examples. 3. (Question is somewhat general) What's the threshold for the necessity of a grant? Does a non-committer have to submit a grant on a single new file? 4. Some of the hyphenation pattern files are licensed under the LPPL (LaTeX project public license, http://www.latex-project.org/lppl.html). We'd like to have clearance to use, modify and distribute files under this license in the FOP project. 5. Can we modify and relicense under the ASL hyphenation pattern files clearly stated as being in the public domain without having a grant but giving credit where possible? 6. We can't use files containing a restriction like Can be used freely for non-commercial purposes., except if we can positively identify the copyright holder and get a grant, right? Thank you in advance for your help! Jeremias Maerki FOP committer and XML PMC member Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/layout/hyphenation - New directory
jeremias2003/03/11 04:52:22 xml-fop/src/java/org/apache/fop/layout/hyphenation - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Japanese Hyphenation was: Re: hyphenation patterns
Konnichiwa. On Fri, 07 Mar 2003 20:22:36 +0100 , J.Pietschmann wrote: Hm. I don't read japanese :-/ JIS X 4051 illustrates line-breaking, justification, writing-mode, letter-spacing, ruby, etc. for Japanese text processing. CSS3 module:text is useful to understand these features in English. http://www.w3.org/TR/css3-text/ This document is probably same as JIS X 4051. Following section is espeically useful for line-breaking. 6. Line breaking 11.2. Hanging punctuation: the 'hanging-punctuation' property Another useful document is following book. http://www.oreilly.com/catalog/cjkvinfo/index.html CJKV Information Processing Chinese, Japanese, Korean Vietnamese Computing By Ken Lunde 1st Edition December 1998 1-56592-224-7, Order Number: 2247 1125 pages Certainly, many japanese people wish that FOP will implement it, but the Japanese Tex hypenation file does not work with current FOP. What's the reason for this? I got the impression both the Japanese and the Chinese TeX versions patched also the TeX source in order to adapt to their respective line breaking rules. I'm not sure how relevant this is to hyphenation. Current FOP can not control any line breaking restrictions. The Asian languages line-breaking strategy has different controls from those of western text. In Japanese, this restriction is called 'kinsoku'. A set of kinsoku character is Open Punctuation, Close Punctuation and Ambiguous Quotation defined in UAX#14. For example, you must not layout U+300C (LEFT CORNER BRACKET) categorized in OP at the end of line and U+3002 (IDEOGRAPHIC FULL STOP) categorized in CP at the head of line. These restriction is estimated at each end of line where is same point as the western soft-hyphenate estimation (i.e. break opportunity estimation). Can FOP currently control these restrictions without any modification? If can, it is my misunderstanding and Japanese Tex hypenation file can use it. But if can not, FOP must implements this feature to use Japanese Tex hypenation file. I think that the cost to implement JIS X 4051 line breaking algorithm is almost equivalent to implement TR14. So I suggested to implement TR14. This is planned for HEAD. The TR14 rules for CJK hyphenation seems to be easy: in absence of any more complicated requirements, hyphenate after every full character. Does the above mentioned standard add such more complicated rules which TR14 does not care too much about? There is no more complicated rules for line-breaking. CSS3 module:text says following :-) http://www.w3.org/TR/css3-text/#line-break-prop | The rules described by JIS X-4051 have been superseded by | the Unicode Technical Report #14. JIS X 4051 line-breaking and TR14 is almost equivalent. In addition, TR14 can use for CJKV and any language with single Unicode Line-Break-Properties file! --- Satoshi Ishigami VIC TOKAI CORPORATION - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Keiron, I assume it was you who wrote two of the mails and put the notifications on the Wiki page? With only the IP address it's difficult to tell (you can register your name in Preferences. Nudge, nudge). Was it Togan, you contacted or one of the other two? Not that we write to the same people twice. Thanks Sorry about that, still trying to sort out how this wiki stuff works. Yes, I sent mails to the email for those who submitted the files. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4316] - Problem of hyphenation in inline-areas
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4316. 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=4316 Problem of hyphenation in inline-areas [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-03-09 17:54 --- The hyphenation property applies to fo:block and fo:character only according to section 7.9.4 hyphenate (Not sure what it should cause for the latter as the spec says Hyphenation may be used .. for the text contained in this object. Odd.) This means you can't use fo:inline or whatever inline FO to temporarily turn off hyphenation. I'd guess this is what keep-together.within-line is for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Hi, * Jeremias Maerki; [EMAIL PROTECTED] on 06 Mar, 2003 wrote: Let me know if you need further information , It would be good if we could find the location where the trhyph.tex in the SuSE ditribution comes from. I don't want to download the whole thing just for verifying one little file. I have asked the maintainer and the reply is a follows answer In the .spec file it isn't listed separately. Thus I assume it's part of the regular teTeX distribution. Hope this helps! /answer So I would asssume all the teTeX distributions have trhypen.tex file and Debian is also strict with licenses so if it's in Debian then it means at least it has the TeX licence Hope this helps. Do you want me to contact Turgut Uyar or have you done it already -- Togan Muftuoglu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
On 07.03.2003 14:36:49 Togan Muftuoglu wrote: Hi, * Jeremias Maerki; [EMAIL PROTECTED] on 06 Mar, 2003 wrote: Let me know if you need further information , It would be good if we could find the location where the trhyph.tex in the SuSE ditribution comes from. I don't want to download the whole thing just for verifying one little file. I have asked the maintainer and the reply is a follows answer In the .spec file it isn't listed separately. Thus I assume it's part of the regular teTeX distribution. Hope this helps! /answer So I would asssume all the teTeX distributions have trhypen.tex file and Debian is also strict with licenses so if it's in Debian then it means at least it has the TeX licence Too many assumptions for me. :-) Hope this helps. Do you want me to contact Turgut Uyar or have you done it already I can do that. I've also found an email address of Pierre MacKay. Keiron, I assume it was you who wrote two of the mails and put the notifications on the Wiki page? With only the IP address it's difficult to tell (you can register your name in Preferences. Nudge, nudge). Was it Togan, you contacted or one of the other two? Not that we write to the same people twice. Thanks Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Japanese Hyphenation was: Re: hyphenation patterns
Satoshi Ishigami wrote: The JIS X 4051 spec is written in Japanese. I don't know whether there is English version spec, or not. Hm. I don't read japanese :-/ Certainly, many japanese people wish that FOP will implement it, but the Japanese Tex hypenation file does not work with current FOP. What's the reason for this? I got the impression both the Japanese and the Chinese TeX versions patched also the TeX source in order to adapt to their respective line breaking rules. I'm not sure how relevant this is to hyphenation. I think that FOP should implements UAX#14(TR14) if possible. For example, AntennaHouse's XSLFormatter implements UAX#14. This is planned for HEAD. The TR14 rules for CJK hyphenation seems to be easy: in absence of any more complicated requirements, hyphenate after every full character. Does the above mentioned standard add such more complicated rules which TR14 does not care too much about? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
XML FOP: Licensing issues with hyphenation pattern files
Hello all (licensing specialists, XML PMC people, fop-devs) (I don't know where might be the best place to discuss this. fop-dev is currently very low-traffic.) The FOP team needs help. In February we realized that we had problematic hyphenation pattern files in our codebase. For example, some of them were derived from GPL-licensed files. Some action has already been taken. I've documented the whole auditing process and status here: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003 I'm at a point where I need some advice on how to proceed from here. Here are the questions, I hope are the right ones and help us to resolve these issues quickly. Before we start here's a little background on the hyphenation stuff: Our hyphenation file are XML files that are derived from TeX hyphenation files (ASCII format). These XML files reside in CVS (xml-fop/src/hyph, formerly xml-fop/hyph). During build they are parsed into Java objects and serialized using Java serialization. These serialized objects are included in the JAR (fop.jar) in the binary distribution. 1. Do our hyphenation files have to be licensed under the ASL? Or is it possible to do something similar we do with Java libraries (external dependencies) such as JUnit and JDOM (add the file to CVS and have an accompanying file containing its license)? 2. If the former (of [1]) is true, we need a grant from the copyright holder of the original file, right? What if the original file is unclear about the copyright holder (multiple names, for example) and about the license (no explicit license, for example)? Please see the Wiki page for examples. 3. (Question is somewhat general) What's the threshold for the necessity of a grant? Does a non-committer have to submit a grant on a single new file? 4. Some of the hyphenation pattern files are licensed under the LPPL (LaTeX project public license, http://www.latex-project.org/lppl.html). We'd like to have clearance to use, modify and distribute files under this license in the FOP project. 5. Can we modify and relicense under the ASL hyphenation pattern files clearly stated as being in the public domain without having a grant but giving credit where possible? 6. We can't use files containing a restriction like Can be used freely for non-commercial purposes., except if we can positively identify the copyright holder and get a grant, right? Thank you in advance for your help! Jeremias Maerki FOP committer and XML PMC member - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
other issues: -pt.xml iseems ok and can be put back? [Jeremias Maaerki] No, it isn't IMO. It forbids commercial usage which is not forbidden by FOP's license. We cannot guarantee that the file is indirectly used for commercial purposes. I could be wrong. I'll ask on on licensing. I already discussed this with Herr Pietschmann and agreed to donate the file to the ASF, provided the credits and bilingual comments are preserved. As I said the previous license was there because of my laziness, I just copied the old one... However, because no one seemed to agree how to insert the licence in the file (short or long). It seems it is already in the codebase, and you my apply the appropriate licence in the way you find appropriate. I can send another copy if needed. I am happy to provide Portuguese-parliant users with a appropriate file, even though this is a very small contribution. By the way, is there a way to turn off the [ERROR] Couldn't find hyphenation pattern pt_br using general language pattern pt instead. message? First, I don't see it as an error, but a warning. Second, it is not relevant to Portuguese: spelling may change from pt-PT to pt-BR, but that does not affect hyphenation. (I know it does for other languages.) Better, is there a way to tell FOP that the same hyphenation rules (file) can be used for any pt[-XX] language values? = Marcelo Jaccoud Amaral Petrobrás (http://www.petrobras.com.br) mailto:[EMAIL PROTECTED] = The way to get things done is not to mind who gets the credit of doing them.--Benjamin Jowett Sorry, I've been busy last week getting my barcode package a new home. Almost forgot about the issues here. On 04.03.2003 01:51:27 Christian Geisert wrote: if I understand it right we are allowed to distribute the LPPL hyphenation patterns (both source and binary) together with FOP if we add the LPPL LICENSE for the patterns (for example in the in the root dir) to the distribution ? (And to be safe I'll ask this on licensing@) I want to ask at licensing first. I've finally received my confirmation for admission to this mailing list. I'll do that today. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Thanks for bringing it up again. It forgot that in the pile of work these license problems generate. I'm sorry. I've updated the Wiki page accordingly. I've submitted some questions today concerning license issues. As soon as I get the answers I'm going to contact you so we can finally readd your file. Thanks for your patience! On 06.03.2003 15:54:08 jaccoud wrote: other issues: -pt.xml iseems ok and can be put back? [Jeremias Maaerki] No, it isn't IMO. It forbids commercial usage which is not forbidden by FOP's license. We cannot guarantee that the file is indirectly used for commercial purposes. I could be wrong. I'll ask on on licensing. I already discussed this with Herr Pietschmann and agreed to donate the file to the ASF, provided the credits and bilingual comments are preserved. As I said the previous license was there because of my laziness, I just copied the old one... However, because no one seemed to agree how to insert the licence in the file (short or long). It seems it is already in the codebase, and you my apply the appropriate licence in the way you find appropriate. I can send another copy if needed. I am happy to provide Portuguese-parliant users with a appropriate file, even though this is a very small contribution. snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Hi, * Jeremias Maerki; [EMAIL PROTECTED] on 06 Mar, 2003 wrote: Thanks for bringing it up again. It forgot that in the pile of work these license problems generate. I'm sorry. I've updated the Wiki page accordingly. I know you have tons of stuff to be sorted our with these licenses. Just to make sure that as the submitter of the tr.xml let me know if tehre is anything I can do to assist * Keiron Liddle; [EMAIL PROTECTED] on 05 Mar, 2003 wrote: Hello Togan, In the FOP project we a trying to clear up some license issues. You donated a turkish hyphenation patterns file. What is the license for that? Did you modify the original tex hyphenations and what was the license for that file? Well I had send an email on Feb 17th 2003 to fop-dev mailinglist about this issue and Jeremias said he would contact Turgut Uyar as there is no license on the header. My modification is only to make FOP use the file and I do not think that is rocket science :-) Nevertheless if you also need grant for my work FOP project may use it Let me know if you need further information , * Jeremias Maerki; [EMAIL PROTECTED] on 14 Feb, 2003 wrote: tr.xml Can't find original file. No licence. Check with author. Well, since I sent out the Turkish hyphenation file I should know where it comes right. The trhyphen.tex is installed from the SuSE 8.1 distro [EMAIL PROTECTED]:~/hangar rpm -qf /usr/share/texmf/tex/generic/hyphen/trhyph.tex tetex-beta.20020207-254 the trhyph.tex file has the following header % A mechanically generated Turkish Hyphenation table for TeX, % using the University of Washington diacritical coding % developed by P. A. MacKay for the Ottoman Texts Project. % Slightly modified by H. Turgut Uyar. Turgut Uyar has the following addres based on google search [EMAIL PROTECTED] Would you like to contact him directly or do you want me to do so ? Although I think you can explain the needs and requirements better than I can -- Togan Muftuoglu -- Togan Muftuoglu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Jeremias Maerki wrote: -pt.xml iseems ok and can be put back? No, it isn't IMO. It forbids commercial usage which is not forbidden by FOP's license. This was the old pt.xml. Should I recommit the new one (released under APL)? I thought I committed it both to HEAD and the maintenance branch... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
* Jeremias Maerki; [EMAIL PROTECTED] on 06 Mar, 2003 wrote: related C source file http://www.ctan.org/tex-archive/language/turkish/hyphen/turk_hyf.c from Pierre A. MacKay which states that in case of commercial distribution the author must be contacted. Which is one more indicator that there could be problems with licensing. The whole TeX thing is a legal nightmare if you ask me. Well, maybe we (or I) are overdoing things here but we (or I) want to do it right. Well shoot I found his papers and the whole thing is about with ottoman turkish ( not the turkish we use today and his original hypenation is tkhyphen.tex ) and now I know why there are some silly suggestions when hyphenating :-) Let me know if you need further information , It would be good if we could find the location where the trhyph.tex in the SuSE ditribution comes from. I don't want to download the whole thing just for verifying one little file. I will ask the tetex maintainer to find I out I'll let you know as soon as I get a reply from him. side note why do I have to work the harder way no spellchecker no hyphenation I started wondering am I the only one using these things under Linux :-( Thanks -- Togan Muftuoglu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Jeremias Maerki wrote: Unfortunately, that's not so easy. You've created a derived work, which can't simply claim full copyright for. In the realm of legal battles, wording matters. Claiming copyright is ok as long as there was substantial work put into creating the Derived Work. Claiming the right to choose a lincense is quite another matter and depends on the license of the Original Work. It turns out that the file mentions multiple authors. Now the question is: Who is the copyright owner Each one is a copyright owner, and perhaps *all* would have to agree on a license change, depending on the license(s) the file had through its history. It's also a matter of courtesy. that can give us the right to use, modify and redistribute that file? Pierre A. MacKay seems to be the original author. H. Turgut Uyar has modified it. Now, who owns the copyright? It depends. For a start, Mr. MacKay apparently didn't create his stuff for the sole purpose of creating hyphenation files. This means the creator of the TeX file can not only claim copyright but also created an Original Work rather than a Derived Work, so he can also choose a license, as long as the original doesn't have a very restrictive license (which would probably also make creating and using the TeX hyphenation file illegal, so I suppose this isn't the case). There is still the problem that the TeX file is explicitely labeled as Mechanically generated, which can be interpreted in a way that there wasn't substantial work put into creating the TeX file, which means it isn't even a Derived work but basically another representation of the original material and Mr. Uyar can't even claim copyright. The slight modifications however should be enough to fix this. Therefore, depending on the interpretation we've either have to ask Mr. Uyar only (interpretation 1) or both (interpretation 2). http://www.ctan.org/tex-archive/language/turkish/hyphen/turk_hyf.c from Pierre A. MacKay which states that in case of commercial distribution the author must be contacted. This is not a real problem as long as the license doens't require that Derived Works must be distributed under a similar condition. that there could be problems with licensing. The whole TeX thing is a legal nightmare if you ask me. Well, the whole Intellectual Property stuff is a nightmare. This is a direct result of assigning substantial value to intangibles... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Togan Muftuoglu wrote: side note why do I have to work the harder way no spellchecker no hyphenation I started wondering am I the only one using these things under Linux :-( Until recently ispell was good enough. It's a bit dated now but you could check Savannah whether anybody picked it up for further development. SourceForge has a handful of projects for spell checkers, most of which should be cross-platform. Which does not imply they can be already used. Then there is MozSpell, and OpenOffice has some sort of spell checker too. Now the really big thing would be a grammar checker. I've still my old notes from 15 years ago for a grammar checker for german and english, but no time at all to do any real coding... :-/ J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Japanese Hyphenation was: Re: hyphenation patterns
On a related matter: some time ago someone mentioned the japanese hyphenation standard. I was not able to find the document, probably all web sites dealing with this are in japanese. Is there anybody listening who can help out? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Did you see my earlier mail to Marcelo Jaccoud Amaral? I'd like to wait until we get answers from licensing@ (especially because of the grant thing). On 06.03.2003 21:45:58 J.Pietschmann wrote: Jeremias Maerki wrote: -pt.xml iseems ok and can be put back? No, it isn't IMO. It forbids commercial usage which is not forbidden by FOP's license. This was the old pt.xml. Should I recommit the new one (released under APL)? I thought I committed it both to HEAD and the maintenance branch... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Japanese Hyphenation was: Re: hyphenation patterns
Konnichiwa. On Thu, 06 Mar 2003 22:32:10 +0100 , J.Pietschmann wrote: On a related matter: some time ago someone mentioned the japanese hyphenation standard. I was not able to find the document, probably all web sites dealing with this are in japanese. Is there anybody listening who can help out? I wrote it in the past. http://marc.theaimsgroup.com/?l=fop-devm=102992807207069w=2 The JIS X 4051 spec is written in Japanese. I don't know whether there is English version spec, or not. Certainly, many japanese people wish that FOP will implement it, but the Japanese Tex hypenation file does not work with current FOP. I think that FOP should implements UAX#14(TR14) if possible. For example, AntennaHouse's XSLFormatter implements UAX#14. UAX#14, Line Breaking Properties http://www.unicode.org/reports/tr14/ Old discussion related with TR14 in fop-dev is http://marc.theaimsgroup.com/?l=fop-devw=2r=1s=tr14q=b --- Satoshi Ishigami VIC TOKAI CORPORATION - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
* J.Pietschmann; [EMAIL PROTECTED] on 06 Mar, 2003 wrote: Togan Muftuoglu wrote: side note why do I have to work the harder way no spellchecker no hyphenation I started wondering am I the only one using these things under Linux :-( Until recently ispell was good enough. It's a bit dated now but you could check Savannah whether anybody picked it up for further development. SourceForge has a handful of projects for spell checkers, most of which should be cross-platform. Which does not imply they can be already used. Then there is MozSpell, and OpenOffice has some sort of spell checker too. It gets off topic yet for the record there is none for Turkish ( Ok there is hyphenation for Turkish under an unknown licence for TeX) I just did for myself a Turkish dictionary to be used with aspell yet with a language like Turkish the wordlist can be as conjugated to a figure like 100.000.000.000 so it is not realistic and possible to have affixes to be able to create such a big list from a 35.000 root words -- Togan Muftuoglu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Sorry, I've been busy last week getting my barcode package a new home. Almost forgot about the issues here. On 04.03.2003 01:51:27 Christian Geisert wrote: if I understand it right we are allowed to distribute the LPPL hyphenation patterns (both source and binary) together with FOP if we add the LPPL LICENSE for the patterns (for example in the in the root dir) to the distribution ? (And to be safe I'll ask this on licensing@) I want to ask at licensing first. I've finally received my confirmation for admission to this mailing list. I'll do that today. other issues: -pt.xml iseems ok and can be put back? No, it isn't IMO. It forbids commercial usage which is not forbidden by FOP's license. We cannot guarantee that the file is indirectly used for commercial purposes. I could be wrong. I'll ask on on licensing. -what about renaming en_GB.xml to en.xml? +1 -I remember *something* about hu.xml but couldn't find it I wrote a mail to the original author but didn't get an answer. The mail didn't bounce, though. -has anybody tried to contact the authors of patterns with unclear licence? Forgot to do that. Sorry. Will do today. I'm strongly for investigating the possibility to make use of the hyphenation packages from OpenOffice. Although they are LGPL we could support them and tell our users where they can get them. Not a very nice thing because our users have to do the license evaluations themselves but at least we are on the safe side. Is anyone out there who would like to do that? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
I've added a detailed Wiki page on the licensing audit for FOP where I intend to track the status of all current issues. http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits To the XML PMC members listening in: I'll follow up with direct questions to licensing@ especially about the LPPL issue. Any help with sorting out the issues is appreciated. Next on my list is to write to some of the hyphenation pattern authors for clarification of the license. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
On 04.03.2003 09:37:51 Jeremias Maerki wrote: -has anybody tried to contact the authors of patterns with unclear licence? Forgot to do that. Sorry. Will do today. Ok, I wrote to the authors of certain files where I see some probability of success in finding the original author and getting permission for further use. Please see the Wiki page for details: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAudits/March2003 This was some really unpleasant work today. I'm looking forward to do some coding again. I hope we can resolve the whole thing soon. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15985. 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=15985 Hyphenation pattern files appear to be invalid [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-03-03 14:47 --- The en.xml file has been removed with the CVS comment: Revision 1.1.2.2 , Tue Feb 18 04:39:10 2003 UTC (13 days, 9 hours ago) by chrisg Branch: fop-0_20_2-maintain Changes since 1.1.2.1: +0 -0 lines FILE REMOVED removed hyphenation patterns with unclear/problematic license I've checked out the latest revision from branch fop-0_20_2-maintain and the problem still exists! The country in the Hyphenator class is empty (null) and therefore it tries to open the en.xml file and not the en_GB.xml file which is the only one left for english hyphenation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15985. 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=15985 Hyphenation pattern files appear to be invalid [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-03 15:22 --- These are two completely different issues. Set the hyphenation language to en_GB until someone donates a hyphenation file for en without license problems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
hyphenation patterns
Ok, if I understand it right we are allowed to distribute the LPPL hyphenation patterns (both source and binary) together with FOP if we add the LPPL LICENSE for the patterns (for example in the in the root dir) to the distribution ? (And to be safe I'll ask this on licensing@) other issues: -pt.xml iseems ok and can be put back? -what about renaming en_GB.xml to en.xml? -I remember *something* about hu.xml but couldn't find it -has anybody tried to contact the authors of patterns with unclear licence? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15985] - Hyphenation pattern files appear to be invalid
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15985. 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=15985 Hyphenation pattern files appear to be invalid [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-01 00:30 --- Mismatch caused by build system change, fixed in 0.20.5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
en_US hyphenation pattern
Anyone know why the en_US hyphenation pattern was dropped in 0.20.5rc2? Thanks, Derrick This electronic transmission is strictly confidential to Smith Nephew and intended solely for the addressee. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: en_US hyphenation pattern
Licensing issues. Koes, Derrick wrote: Anyone know why the en_US hyphenation pattern was dropped in 0.20.5rc2? Thanks, Derrick -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
