DO NOT REPLY [Bug 17194] New: - LineArea Leader fails in 0.20.5rc2
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=17194. 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=17194 LineArea Leader fails in 0.20.5rc2 Summary: LineArea Leader fails in 0.20.5rc2 Product: Fop Version: 0.20.5 Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: page-master/layout AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This bug did not exist in 0.20.5rc Making portrait pages on A4 paper (210mmx297mm) Transforming vol1.fo to PDF [DEBUG] Input mode: [DEBUG] FO [DEBUG] fo input file: vol1.fo [DEBUG] Output mode: [DEBUG] pdf [DEBUG] output file: NC3TA-Vol1-v4.pdf [DEBUG] OPTIONS [DEBUG] no user configuration file is used [default] [DEBUG] debug mode on [DEBUG] dump configuration [DEBUG] quiet mode on [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] base directory: file:/home/js/work/noswg/xml-nc3ta/tools/build/pdf/ [INFO] FOP 0.20.5rc2 [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [INFO] [1] [INFO] [2 (blank)] [DEBUG] Last page-sequence produced 2 pages. [INFO] [3] [ERROR] org.apache.fop.layout.LineArea$Leader org.apache.fop.apps.FOPException: org.apache.fop.layout.LineArea$Leader at org.apache.fop.apps.CommandLineStarter.run(CommandLineStarter.java:74) at org.apache.fop.apps.Fop.main(Fop.java:19) - java.lang.ClassCastException: org.apache.fop.layout.LineArea$Leader at org.apache.fop.layout.LineArea.verticalAlign(LineArea.java:901) at org.apache.fop.layout.BlockArea.addLineArea(BlockArea.java:91) at org.apache.fop.layout.BlockArea.end(BlockArea.java:176) at org.apache.fop.fo.flow.Block.layout(Block.java:246) at org.apache.fop.fo.flow.Block.layout(Block.java:206) at org.apache.fop.fo.flow.Block.layout(Block.java:206) at org.apache.fop.fo.flow.Block.layout(Block.java:206) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:111) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:68) at org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:352) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:290) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:218) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.fop.apps.Driver.render(Driver.java:457) at org.apache.fop.apps.CommandLineStarter.run(CommandLineStarter.java:69) at org.apache.fop.apps.Fop.main(Fop.java:19) Java Result: 2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 17.02.2003 17:36:13 Victor Mote wrote: Jeremias Maerki wrote: Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. - Find Apache-compatible hyphenation files. I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. I've tried to locate the sources you mentioned on the net, but haven't succeeded. Can you give us a URL? - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. This would be unnecessary if we start with the right base build from there. - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) I have no objection to this, but the conversion does not look very complicated, and if we distribute our own, then there is no need for it. Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Well, that depends on the licence. We cannot just simply credit Knuth TeX and apply the Apache licence. Jörg's analysis of the situation is pretty accurate IMO. This is a non-trivial matter. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs fonts.xml
jeremias2003/02/19 01:30:52 Modified:src/documentation/content/xdocs fonts.xml Log: Added note for applicability to PDF and PS renderers only. Revision ChangesPath 1.5 +9 -0 xml-fop/src/documentation/content/xdocs/fonts.xml Index: fonts.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/fonts.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- fonts.xml 12 Dec 2002 10:59:33 - 1.4 +++ fonts.xml 19 Feb 2003 09:30:51 - 1.5 @@ -12,6 +12,15 @@ /header body section +titleImportant/title +pThe information on this page applies primarily to the PDF renderer. The PostScript renderer +also supports custom fonts but doesn't support font embedding, yet. This page does +strongnot/strong apply to the AWT, PCL, MIF and other renderers./p +pThe AWT renderer relies upon AWT to provide the available fonts. And it's the printer +driver of your operating system that decides if a font is embedded when using the AWT +renderer./p + /section + section titleStatus/title pFOP (building PDF files) normally supports only the base 14 font package defined in the Adobe PDF specification. That includes the following fonts: Helvetica, Times, Courier, Symbol and ZapfDingbats. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Positive responses from XML PMC on rotation scheme for project representatives
I've got positive responses from the XML PMC on Keiron's idea of a rotating scheme for project representatives. There will be discussions on [EMAIL PROTECTED] in the near future to adjust the XML charter to today's requirements. What needs to be addressed is the oversight factor: Too high a frequency of rotating people in and out of the XML PMC might have a negative impact. I can't tell if 6 months is too fast. I think it could work. I would like to encourage anyone interested in participating in the discussions when they start on [EMAIL PROTECTED] Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Hyphenation patterns included in fop-0.20.5rc2
FOP version 0.20.5rc2 contains the following hyphenation files: - en_GB.xml: British English - es.xml: Spanish - fi.xml: Finnish - hu.xml: Hungarian - it.xml: Italian - pl.xml: Polish Christian, I'm most uneasy about hu.xml. It's the only one that IMO doesn't have an explicit statement that the file is in the public domain. The original (?) file I found contained a notice about free distribution, but our file doesn't contain a unambiguous reference to the original file, so I must assume that the copyrights are not entirely clear. Therefore, I am -1 (veto) on keeping that one for the moment. Does anyone disagree? On 18.02.2003 17:51:42 Clay Leeds wrote: Esteemed feathery FOPpers, BTW, congrats stuff on the release! I just ran it, and it didn't give me an error! ;-) Would you let us know which hyphenation files are included with FOP 0.20.5rc2? I think that would be useful information to include in the fop-dev fop-user mailing lists for archival/searching purposes, and the only reference to what is included is en_GB. It might also be useful to include in the reply, the status of other hyphenation patterns (and links if they exist). I checked out the current installation, and had a tough time finding info on Hyphenation. After doing a search on the fop-0.20.5rc2 directory, I found this file: fop-0.20.5rc2\examples\fo\basic\hyphen.fo Is that example the sum total of the hyphenation stuff in FOP? Or was everything removed (Christian indicated removal of some hyphenation patterns)? If it's there, then I couldn't find it. If it's not, then the RelNotes should read most hyphenation patterns... Thanks for the great effort! It looks *great*! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Table Border
Hello All, I am very new to FOP and I am using FOP in my Project. I want to create tables with border in my application, I am able to create tables but without borders can any one suugest me a solution to get the borders for table. Thanks in Advance, Venkata Suresh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Table Border
Use in the fo:table tag the following things: border-left-color border-left-style border-left-width border-top-color border-top-style border-top-width border-right-color border-right-style border-right-width border-bottom-color border-bottom-style border-bottom-width greetings, Jochen Jochen Maes ICT Development KBC Securities (kbcsecurities.com) Havenlaan 12 Avenue du Port SIF 8683 B-1080 Brussels Belgium Tel: +32 2 429 96 81 GSM: +32 496 57 90 99 E-mail : [EMAIL PROTECTED] This message and any attachments hereto are for the named person's use only. It may contain confidential, proprietary or legally privileged information. You may not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. If you have received this e-mail message without being the intended recipient, please notify KBC Securities promptly and delete this e-mail. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of KBC Securities. KBC Securities reserves the right to monitor all e-mail communications through its networks and any messages addressed to, received or sent by KBC Securities or its employees are deemed to be professional in nature. The sender or recipient of any messages to or of KBC Securities agrees that those may be read by other employees of KBC Securities than the stated recipient or sender in order to ensure the continuity of work-related activities and allow supervision thereof. KBC Securities does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of, or reliance on, the information. Annapu, Venkatasuresh To: [EMAIL PROTECTED] venkatasuresh.annapcc: [EMAIL PROTECTED] Subject: Table Border 19/02/2003 11:26 Please respond to fop-dev Hello All, I am very new to FOP and I am using FOP in my Project. I want to create tables with border in my application, I am able to create tables but without borders can any one suugest me a solution to get the borders for table. Thanks in Advance, Venkata Suresh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Table Border
Venkata, Just have an example as an extra: fo:table border-top-style=solid border-top-width=1pt border-left-style =solid border-left-width=1pt border-bottom-style=solid border-bottom-width=1pt border-right-style=solid border-right-width= 1pt space-before.optimum=15pt padding=6pt fo:table-column column-width=6cm/ fo:table-column column-width=5cm/ fo:table-column column-width=4cm/ fo:table-column column-width=1.7cm/ fo:table-body/fo:table-body /fo:table greetings, Jochen Maes ICT Development KBC Securities (kbcsecurities.com) Havenlaan 12 Avenue du Port SIF 8683 B-1080 Brussels Belgium Tel: +32 2 429 96 81 GSM: +32 496 57 90 99 E-mail : [EMAIL PROTECTED] This message and any attachments hereto are for the named person's use only. It may contain confidential, proprietary or legally privileged information. You may not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. If you have received this e-mail message without being the intended recipient, please notify KBC Securities promptly and delete this e-mail. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of KBC Securities. KBC Securities reserves the right to monitor all e-mail communications through its networks and any messages addressed to, received or sent by KBC Securities or its employees are deemed to be professional in nature. The sender or recipient of any messages to or of KBC Securities agrees that those may be read by other employees of KBC Securities than the stated recipient or sender in order to ensure the continuity of work-related activities and allow supervision thereof. KBC Securities does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of, or reliance on, the information. Annapu, Venkatasuresh To: [EMAIL PROTECTED] venkatasuresh.annapcc: [EMAIL PROTECTED] Subject: Table Border 19/02/2003 11:26 Please respond to fop-dev Hello All, I am very new to FOP and I am using FOP in my Project. I want to create tables with border in my application, I am able to create tables but without borders can any one suugest me a solution to get the borders for table. Thanks in Advance, Venkata Suresh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Positive responses from XML PMC on rotation scheme for projectrepresentatives
On Wed, 19 Feb 2003, Jeremias Maerki wrote: I've got positive responses from the XML PMC on Keiron's idea of a rotating scheme for project representatives. There will be discussions on [EMAIL PROTECTED] in the near future to adjust the XML charter to today's requirements. What needs to be addressed is the oversight factor: Too high a frequency of rotating people in and out of the XML PMC might have a negative impact. I can't tell if 6 months is too fast. Staggered rotation would solve that; i.e. do one of the two per code-bases representatives. That would mean an election every 3 months for one rep per code base. Or if we make the term a year; one election for one rep every 6 months. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ready to go again
On 18.02.2003 18:38:43 Victor Mote wrote: OK, I am ready to jump in do some work. Sorry for being out of action for so long. Hey, no apology required. The threads that I would like to complete, or at least resolve, first, are: 1. Documentation. The main problem here is the web site generation, but it seemed to me that Peter and some others may have gotten that working. If so, is the readme doc up-to-date? (The last time I tried to run it, in December, the generation failed with errors). 2. Fonts. Jeremias had some brief design conversations a few weeks ago. He argued for an interface, I argued for a concrete facade implementation. He is probably getting his doctrine from the Design Patterns book, and he is probably correct. Partially. More from experience working with Avalon for the more than 2 years. Another principle taught in that book is that inheritance tends to be overrused, and that is specifically what I am trying to prevent with my approach. In my mind, there is tension between encapsulation and inheritance. So, if we can hide all of the implementation details behind the interface just as well as we can behind a facade, so that layout doesn't know or care what kind of font it is dealing with, then we are OK. Ideally, we want to do the same thing for the renderers, if possible. This is getting academic. (no offense intended, I'm just not used to talk about this on an overly theoretic level) Let me put it that way: An interface establishes a clear contract between to subsystems. An implementation of the interface might be a direct implementation of some functionality or an adapter to some existing functionality. The user of the interface doesn't (and shouldn't) care about implementation details. This is different when you base your work on an abstract base class for example. Things like logging or lifecycle management influence this class and all its decendants directly. That may mix concerns (see Avalon: Separation of Concerns). I hope this makes sense. What I'm going for is this: I'd like to be prepared when it comes to looking up services from an Avalon container. Avalon-based system lookup (work-) interfaces. All lifecycle is handled by the container. I don't want to dictate how you have to develop the font stuff and I don't want another lengthy discussion started with my comments above. It may even be best if you did it your way for now (we need to get the ball rolling) and we adjusted the code to the Avalon environment as soon as I have set it up. I'm still trying to get my mind focused on that task (difficult with all the licencing, PMC, support stuff going on). Anyway, it high priority on my side and I'm still ready to help you on the font stuff. By the way: Do we have to vote for the full adoption of Avalon in FOP? I still sense some resistance on this topic. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Hyphenation patterns included in fop-0.20.5rc2
Thanks for the quick response. Can this information be added to the release notes and/or readme? I see that en_GB.xml exists but what's the story on what I would assume would be called en_US.xml (US English hyphenation patterns file)? Does it exist? Is it missing due to licensing issues? Also, I've searched for filenames text contents in my fop installations (.4 .5rc2) and I haven't found the hyphenation pattern files. Where are they stored? Jeremias Maerki wrote: FOP version 0.20.5rc2 contains the following hyphenation files: - en_GB.xml: British English - es.xml: Spanish - fi.xml: Finnish - hu.xml: Hungarian - it.xml: Italian - pl.xml: Polish Christian, I'm most uneasy about hu.xml. It's the only one that IMO doesn't have an explicit statement that the file is in the public domain. The original (?) file I found contained a notice about free distribution, but our file doesn't contain a unambiguous reference to the original file, so I must assume that the copyrights are not entirely clear. Therefore, I am -1 (veto) on keeping that one for the moment. Does anyone disagree? FWIW, I would agree. It should be relatively easy for users to download the hyphenation files (especially if we provide a list with links! ;-). I certainly don't think it's worth the risk to include files with questionable licensing issues. -- 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]
Re: Licence issues in hyphenation patterns
J.Pietschmann [EMAIL PROTECTED] Sorry for being unclear and short-spoken, I didn't meant to offend you. Jeez, I was not. I think _I_ was not clear when posting the files. However, did you really start with an empty file in an editor and typed in all the pattern strings? There are Original Works. If someone creates a new file by typing stuff into an editor he creates an Original Work. Running the hyphenation pattern programm on a properly marked up dictionary or corpus is probably also creating an Original Work, with certain caveats (it wasn't, for example, if the dictionary was marked up by someone else for the sole purpose of serving as input for the hyphenation pattern program). [...] Again, you probably used some data to derive the patterns, be it a corpus or a TeX file. [...] Creating patterns for Portuguese is much simpler than with English. While hyphenation in English is driven by etymology and is highly irregular (hence the pattern generator procedures), in Portuguese it is dictated solely by prosody and is highly regular. Only a few pathologic cases with irregular pronunciation must be treated as exceptions. So what I did was to write patterns for all possible combinations of letters. Again, that was possible because there are lexical rules restricting the valid combinations. When a new word enters a Portuguese dictionary, it must conform to these rules -- for example, basket became basquete, because 'k' is not part of our alphabet and words cannot end with a 't'. This happens with other languages as well, (e.g. Spanish and Turkish), and this affects the size of the hyphenation files, which are much smaller. And while the English hyphenation patterns can fail for some new strange word that depparts statistically from the others, the Portuguese patterns work with any word, past or future, that conforms to the current (2003 AD) Portuguese lexical rules. That means the only other works I used to write the files were: - a Portuguese grammar, listed in the file; - a Portuguese dictionary, to check some spellings, also referenced; - the FOP documentation and a file describing the TEX algorithm (I thought it wasn't necessary to reference that). In this file you generously transferred your copyright to the ASF (this fact crept into my brain only after I committed the file). Actually I did this in my spare time, and only some months later I came to use it in a company project that used FOP (with my influence, of course). So the file is not property of Petrobrás, it is mine. But my employee wouldn't care anyway. Petrobrás' business is oil, not software, we only keep to us software that carries proprietary technology (our petrochemical process simulator, for example). I am donating the hyphenation file to the ASF, and although it would be nice to keep the copyright, I think that would hamper future enhancements, or not? Sorry, I'm not much into this legal stuff, it alocates too many neurons, and my resources are scarse... :-) = Marcelo Jaccoud Amaral Petrobrás (http://www.petrobras.com.br) mailto:[EMAIL PROTECTED] = I'm not tense, I'm just terribly, terribly alert. Para: [EMAIL PROTECTED] 18/02/2003 19:23 cc: Favor responder aAssunto: Re: Licence issues in hyphenation patterns fop-dev [EMAIL PROTECTED] wrote: I didn't modify the old pt.xml file, I wrote a new one entirely from scratch. ... The original TEX file was made by Paulo Rezende, now back in Brazil (at Unicamp), and it was converted by Paulo Soares (working presently in Portugal), who I contacted at the time. He posted no objection of us replacing the file. Asking him was nice, but from a legal point of view, he can't sue anyone for replacing his file by something else :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence issues in hyphenation patterns
Jeremias Maerki wrote: I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. I've tried to locate the sources you mentioned on the net, but haven't succeeded. Can you give us a URL? I don't know where they are on the net, but I'll be happy to email them to you. Or, if you have a Red Hat distribution, you might be able to find them there. Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Well, that depends on the licence. We cannot just simply credit Knuth TeX and apply the Apache licence. Jörg's analysis of the situation is pretty accurate IMO. This is a non-trivial matter. Maybe I missed something in Joerg's analysis, or maybe I forgot to summarize the Knuth/TeX license. Essentially, it is this: Use this software for anything that you wish, but don't modify it and call it TeX. In other words, Knuth retains control over TeX, but has no objection to anyone taking that code starting another project with it -- he just doesn't want any confusion over what is TeX. I agree that it is a non-trivial matter, and that we need to respect everyone's rights, so if I have misunderstood something, please set me straight. Otherwise, I think we really can simply apply the Apache license to that work. The credits are simple courtesy. I just think it is better to start with something that works, even if incomplete, and have contributors add to it to make it complete, than to try to mess with the other licenses. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 18.02.2003 22:07:13 J.Pietschmann wrote: snip/ The LPPL'd hyphenation have to be checked thouroughly because of LPPL 1. Condition 2 does not apply. Condition 7 is fulfilled by keeping the file under LPPL. 3 is probably trivially ok as mentioned above. 4, 5 and 6 can be easily checked and corrected, and 8(B) should be easy too. I can look into it this weekend. Thank you, that'd be great! It didn't occur to me that we could leave the licence of some source files as is. I thought that would only apply to third-party JARs. Nonetheless, before I'd like to allow any LPPL file to reside in our repository I want the approval from the board or licencing@. At least the process of officially approving other licences and publishing the results for all to see has kicked off. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 19.02.2003 17:56:27 Victor Mote wrote: Jeremias Maerki wrote: I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. I've tried to locate the sources you mentioned on the net, but haven't succeeded. Can you give us a URL? I don't know where they are on the net, but I'll be happy to email them to you. Or, if you have a Red Hat distribution, you might be able to find them there. Would you email them to me? Thanks! Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Well, that depends on the licence. We cannot just simply credit Knuth TeX and apply the Apache licence. Jörg's analysis of the situation is pretty accurate IMO. This is a non-trivial matter. Maybe I missed something in Joerg's analysis, or maybe I forgot to summarize the Knuth/TeX license. Essentially, it is this: Use this software for anything that you wish, but don't modify it and call it TeX. In other words, Knuth retains control over TeX, but has no objection to anyone taking that code starting another project with it -- he just doesn't want any confusion over what is TeX. I agree that it is a non-trivial matter, and that we need to respect everyone's rights, so if I have misunderstood something, please set me straight. Otherwise, I think we really can simply apply the Apache license to that work. The credits are simple courtesy. I just think it is better to start with something that works, even if incomplete, and have contributors add to it to make it complete, than to try to mess with the other licenses. It's ok. I thought there would be more than this single sentence attached to the sources. I just wanted to check on the original licence. You could be right about apply the Apache licence. Does everbody agree in this case? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Looking for the best location for a barcode library
Jeremias Maerki wrote: Currently, the project's a one-man show, so I think it doesn't qualify as a candiate for an Apache (sub-)project. But who knows. That's why I ask around first. Being a FOP committer I could also add it to FOP but I think the project isn't exclusively useful in that context. I agree. There are some other parts of FOP that would seem to be similar -- fonts and hyphenation come to mind. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Hyphenation patterns included in fop-0.20.5rc2
On 19.02.2003 16:47:30 Clay Leeds wrote: Thanks for the quick response. Can this information be added to the release notes and/or readme? I'll put it on my todo list if nobody does it before I do. I see that en_GB.xml exists but what's the story on what I would assume would be called en_US.xml (US English hyphenation patterns file)? Does it exist? Is it missing due to licensing issues? The removal of hyphenation files was exclusively triggered by licence issues. We don't have an en_US.xml that we're confortble with ATM. Also, I've searched for filenames text contents in my fop installations (.4 .5rc2) and I haven't found the hyphenation pattern files. Where are they stored? In the binary distribution they are in the hyph directory of fop.jar (in compiled form). In the source distribution they are under src/hyph as XML files. Jeremias Maerki wrote: FOP version 0.20.5rc2 contains the following hyphenation files: - en_GB.xml: British English - es.xml: Spanish - fi.xml: Finnish - hu.xml: Hungarian - it.xml: Italian - pl.xml: Polish Christian, I'm most uneasy about hu.xml. It's the only one that IMO doesn't have an explicit statement that the file is in the public domain. The original (?) file I found contained a notice about free distribution, but our file doesn't contain a unambiguous reference to the original file, so I must assume that the copyrights are not entirely clear. Therefore, I am -1 (veto) on keeping that one for the moment. Does anyone disagree? FWIW, I would agree. It should be relatively easy for users to download the hyphenation files (especially if we provide a list with links! ;-). I certainly don't think it's worth the risk to include files with questionable licensing issues. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence issues in hyphenation patterns
Jeremias Maerki wrote: On 18.02.2003 22:07:13 J.Pietschmann wrote: snip/ The LPPL'd hyphenation have to be checked thouroughly because of LPPL 1. Condition 2 does not apply. Condition 7 is fulfilled by keeping the file under LPPL. 3 is probably trivially ok as mentioned above. 4, 5 and 6 can be easily checked and corrected, and 8(B) should be easy too. I can look into it this weekend. Thank you, that'd be great! It didn't occur to me that we could leave the licence of some source files as is. I thought that would only apply to third-party JARs. Nonetheless, before I'd like to allow any LPPL file to reside in our repository I want the approval from the board or licencing@. At least the process of officially approving other licences and publishing the results for all to see has kicked off. I don't think the LPPL works at all for us. The preamble says: You may distribute a complete, unmodified copy of The Program. Distribution of only part of The Program is not allowed. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: ready to go again
Jeremias Maerki wrote: don't want another lengthy discussion started with my comments above. It may even be best if you did it your way for now (we need to get the ball rolling) and we adjusted the code to the Avalon environment as soon as I have set it up. I'm still trying to get my mind focused on that task Actually, I was trying to concede to your approach. Your point about getting started is well taken, so I will. I am still not up to speed on Avalon, but will try to keep after that in parallel with this work. By the way: Do we have to vote for the full adoption of Avalon in FOP? I still sense some resistance on this topic. I am still too ignorant on the topic to have an opinion. Joerg's comments about an extra burden on the users worried me, and made me think that I have misunderstood the whole concept of what Avalon should be doing for us. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Looking for the best location for a barcode library
Hi there Before I open a SourceForge project I wanted to ask if there might be interest in a barcode library/framework here at Apache. I started to develop the library two years ago and it has already seen real-life use in two projects with my last employer. I'm in the process of doing a major refactoring cycle with the goal of making the whole package opensource. Features: - written in Java - Implementations of the following 1D-barcodes: - Interleaved 2 of 5 - Code39 - Codabar - Code128 - EAN13 and UPC-A (only partially impl.) - Output formats: - SVG (as W3C DOM and JDOM) - AWT (planned, first experiments) - Bitmaps (planned) - Integration - Xalan extension (generating SVG) - Servlet (generating SVG) - FOP extension (in progress) - Other planned features: - support for 2D-barcodes (ex. DataMatrix) Currently, the project's a one-man show, so I think it doesn't qualify as a candiate for an Apache (sub-)project. But who knows. That's why I ask around first. Being a FOP committer I could also add it to FOP but I think the project isn't exclusively useful in that context. Thanks in advance for any feedback! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr PageLayoutManager.java RetrieveMarkerLayoutManager.java BlockLayoutManager.java
keiron 2003/02/19 18:47:45
Modified:src/org/apache/fop/area AreaTree.java AreaTreeModel.java
PageViewport.java
src/org/apache/fop/layoutmgr PageLayoutManager.java
RetrieveMarkerLayoutManager.java
BlockLayoutManager.java
Log:
implement position and boundary for markers
Revision ChangesPath
1.15 +10 -1 xml-fop/src/org/apache/fop/area/AreaTree.java
Index: AreaTree.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/AreaTree.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- AreaTree.java 22 Dec 2002 22:40:31 - 1.14
+++ AreaTree.java 20 Feb 2003 02:47:44 - 1.15
@@ -73,6 +73,15 @@
}
/**
+ * Get the area tree model for this area tree.
+ *
+ * @return AreaTreeModel the model being used for this area tree
+ */
+public AreaTreeModel getAreaTreeModel() {
+return model;
+}
+
+/**
* Start a new page sequence.
* This signals that a new page sequence has started in the document.
* @param title the title of the new page sequence or null if no title
1.3 +33 -1 xml-fop/src/org/apache/fop/area/AreaTreeModel.java
Index: AreaTreeModel.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/AreaTreeModel.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AreaTreeModel.java23 Jan 2003 18:59:07 - 1.2
+++ AreaTreeModel.java20 Feb 2003 02:47:44 - 1.3
@@ -11,6 +11,9 @@
* This is the model for the area tree object.
* The model implementation can handle the page sequence,
* page and extensions.
+ * The mathods to acces the page viewports can only
+ * assume the PageViewport is valid as it remains for
+ * the life of the area tree model.
*/
public abstract class AreaTreeModel {
/**
@@ -36,4 +39,33 @@
* Signal the end of the document for any processing.
*/
public abstract void endDocument();
+
+/**
+ * Get the page sequence count.
+ * @return the number of page sequences in the document.
+ */
+public abstract int getPageSequenceCount();
+
+/**
+ * Get the title for a page sequence.
+ * @param count the page sequence count
+ * @return the title of the page sequence
+ */
+public abstract Title getTitle(int count);
+
+/**
+ * Get the page count.
+ * @param seq the page sequence to count.
+ * @return returns the number of pages in a page sequence
+ */
+public abstract int getPageCount(int seq);
+
+/**
+ * Get the page for a position in the document.
+ * @param seq the page sequence number
+ * @param count the page count in the sequence
+ * @return the PageViewport for the particular page
+ */
+public abstract PageViewport getPage(int seq, int count);
+
}
1.14 +84 -13xml-fop/src/org/apache/fop/area/PageViewport.java
Index: PageViewport.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/PageViewport.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- PageViewport.java 19 Feb 2003 05:43:24 - 1.13
+++ PageViewport.java 20 Feb 2003 02:47:44 - 1.14
@@ -16,6 +16,8 @@
import java.util.HashMap;
import java.util.Iterator;
+import org.apache.fop.fo.properties.RetrievePosition;
+
/**
* Page viewport that specifies the viewport area and holds the page contents.
* This is the top level object for a page and remains valid for the life
@@ -43,8 +45,10 @@
// hashmap of markers for this page
// start and end are added by the fo that contains the markers
-private Map markerStart = null;
-private Map markerEnd = null;
+private Map markerFirstStart = null;
+private Map markerLastStart = null;
+private Map markerFirstEnd = null;
+private Map markerLastEnd = null;
/**
* Create a page viewport.
@@ -176,27 +180,94 @@
}
/**
- * Add the start markers for this page.
+ * Add the markers for this page.
+ * Only the required markers are kept.
+ * For first-starting-within-page it adds the markers
+ * that are starting only if the marker class name is not
+ * already added.
+ * For first-including-carryover it adds any marker if
+ * the marker class name is not already added.
+ * For last-starting-within-page it adds all marks that
+ * are starting, replacing earlier markers.
+ *
Long licence
That's it. The board has finally spoken. We need to change to long licences in our codebase. Anyone out there with free time? If not, I can do it. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17194] - LineArea Leader fails in 0.20.5rc2
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=17194. 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=17194 LineArea Leader fails in 0.20.5rc2 --- Additional Comments From [EMAIL PROTECTED] 2003-02-20 07:33 --- Created an attachment (id=4936) Fails when generating TOC (Maybe caused by Pietch fix from feb 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Long licence
Jeremias Maerki wrote: That's it. The board has finally spoken. We need to change to long licences in our codebase. Anyone out there with free time? If not, I can do it. I can help you. Should we change both codebases? -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
