Re: Invalid Javadoc
Hi Eric, This site is not maintained by FOP team and appears to be out of date. Currently, the only way to get an up-to-date javadocs is to make it yourself: see [1]. [1] http://xmlgraphics.apache.org/fop/trunk/compiling.html#build-script or http://xmlgraphics.apache.org/fop/0.95/compiling.html#build-script -- Pascal Le 06/07/2010 20:15, Eric Douglas a écrit : Is this a correct website for the Javadoc? Was it given docs for an invalid version? I notice it's path shows beta, but it appears this class is invalid.. _http://docjar.com/docs/api/org/apache/fop/render/pdf/fonts/LazyFont.html_
Re: request for complex scripts branch with commit access
Any committer is allowed to create a development branch, preferably with some advance warning. The thing is: the ASF doesn't give away commit rights just upon request. Committership has to be earned by regular contributions. See: http://www.apache.org/foundation/how-it-works.html What we can do for you is to create a branch for your patches and then process (review, apply) them. That way you can improve the branch incrementally and we can get to know you. When you bombard us with good contributions, you can be pretty sure to be fast-tracked to committership. At least, you already have one task behind you: Your ICLA is on file with the ASF. That's good. On 07.07.2010 07:08:29 Glenn Adams wrote: What is the policy for branch creation? In particular, would it be possible to create a branch to which I could commit changes to add the following support: - complex scripts (e.g., arabic, indic) - advanced typographic font table support (e.g., gpos/gsub/jstf, ...) - writing-mode, unicode-bidi, direction traits - inline-progression-direction, block-progress-direction, shift-direction traits - unicode bidi algorithm Due to the extent of the changes to support the above, this may be a complex patch to manage without a branch, as can be seen by my current set of added/modified files listed below. Regards, Glenn Adams A src/java/org/apache/fop/fonts/DiscontinuousAssociationException.java M src/java/org/apache/fop/fonts/apps/TTFReader.java A src/java/org/apache/fop/fonts/GlyphTable.java M src/java/org/apache/fop/fonts/MultiByteFont.java A src/java/org/apache/fop/fonts/Positionable.java A src/java/org/apache/fop/fonts/GlyphUtils.java A src/java/org/apache/fop/fonts/GlyphSubtable.java M src/java/org/apache/fop/fonts/Font.java A src/java/org/apache/fop/fonts/GlyphCoverageTable.java A src/java/org/apache/fop/fonts/GlyphPositioningSubtable.java M src/java/org/apache/fop/fonts/truetype/TTFFile.java M src/java/org/apache/fop/fonts/LazyFont.java A src/java/org/apache/fop/fonts/GlyphPositioning.java A src/java/org/apache/fop/fonts/ArabicScriptProcessor.java A src/java/org/apache/fop/fonts/GlyphSequence.java M src/java/org/apache/fop/fonts/type1/AFMFile.java A src/java/org/apache/fop/fonts/GlyphSubstitutionTable.java M src/java/org/apache/fop/fonts/FontReader.java A src/java/org/apache/fop/fonts/Substitutable.java M src/java/org/apache/fop/fo/FOText.java M src/java/org/apache/fop/fo/Constants.java M src/java/org/apache/fop/fo/extensions/svg/SVGDOMContentHandlerFactory.java M src/java/org/apache/fop/fo/PropertyList.java M src/java/org/apache/fop/fo/FObj.java M src/java/org/apache/fop/fo/flow/table/Table.java M src/java/org/apache/fop/fo/pagination/SimplePageMaster.java M src/java/org/apache/fop/fo/pagination/PageSequence.java M src/java/org/apache/fop/fo/pagination/Region.java M src/java/org/apache/fop/fo/properties/DimensionPropertyMaker.java M src/java/org/apache/fop/fo/properties/CorrespondingPropertyMaker.java M src/java/org/apache/fop/fo/properties/IndentPropertyMaker.java M src/java/org/apache/fop/fo/FOPropertyMapping.java A src/java/org/apache/fop/traits/Direction.java A src/java/org/apache/fop/traits/WritingMode.java M src/java/org/apache/fop/area/BodyRegion.java M src/java/org/apache/fop/area/MainReference.java M src/java/org/apache/fop/area/AreaTreeParser.java M src/java/org/apache/fop/area/AreaTreeModel.java M src/java/org/apache/fop/area/PageViewport.java M src/java/org/apache/fop/area/Page.java M src/java/org/apache/fop/area/inline/WordArea.java M src/java/org/apache/fop/area/inline/TextArea.java M src/java/org/apache/fop/area/inline/Viewport.java M src/java/org/apache/fop/area/Span.java M src/java/org/apache/fop/area/RegionReference.java M src/java/org/apache/fop/area/PageSequence.java M src/java/org/apache/fop/area/Area.java M src/java/org/apache/fop/area/Trait.java M src/java/org/apache/fop/area/RegionViewport.java M src/java/org/apache/fop/area/Block.java M src/java/org/apache/fop/util/CharUtilities.java Jeremias Maerki
Re: PageViewport/Page as subclasses of Area rather than AreaTreeObject?
Glenn, not sure how that came to be. Well, Area defines various features that probably won't be used for Page/PageViewport. But if it helps, we can surely revisit that. On 07.07.2010 07:16:54 Glenn Adams wrote: Is there a good/strong reason why PageViewport and Page are defined as subclasses of AreaTreeObject rather than Area? In my recent work to add full support for the writing-system trait, I found it to be more consistent to redefine these as subclasses of Area. After all, the XSL-FO spec defines them as a viewport/reference area pair as generated by fo:page-sequence, so notionally speaking, they should be first class areas. By the way, changing them to Area did not produce any regression in the junit tests, so it does not seem a breaking change at first order. Regards, Glenn Jeremias Maerki
Re: request for complex scripts branch with commit access
understood; thanks for the process info; On Wed, Jul 7, 2010 at 5:41 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Any committer is allowed to create a development branch, preferably with some advance warning. The thing is: the ASF doesn't give away commit rights just upon request. Committership has to be earned by regular contributions. See: http://www.apache.org/foundation/how-it-works.html What we can do for you is to create a branch for your patches and then process (review, apply) them. That way you can improve the branch incrementally and we can get to know you. When you bombard us with good contributions, you can be pretty sure to be fast-tracked to committership. At least, you already have one task behind you: Your ICLA is on file with the ASF. That's good. On 07.07.2010 07:08:29 Glenn Adams wrote: What is the policy for branch creation? In particular, would it be possible to create a branch to which I could commit changes to add the following support: - complex scripts (e.g., arabic, indic) - advanced typographic font table support (e.g., gpos/gsub/jstf, ...) - writing-mode, unicode-bidi, direction traits - inline-progression-direction, block-progress-direction, shift-direction traits - unicode bidi algorithm Due to the extent of the changes to support the above, this may be a complex patch to manage without a branch, as can be seen by my current set of added/modified files listed below. Regards, Glenn Adams A src/java/org/apache/fop/fonts/DiscontinuousAssociationException.java M src/java/org/apache/fop/fonts/apps/TTFReader.java A src/java/org/apache/fop/fonts/GlyphTable.java M src/java/org/apache/fop/fonts/MultiByteFont.java A src/java/org/apache/fop/fonts/Positionable.java A src/java/org/apache/fop/fonts/GlyphUtils.java A src/java/org/apache/fop/fonts/GlyphSubtable.java M src/java/org/apache/fop/fonts/Font.java A src/java/org/apache/fop/fonts/GlyphCoverageTable.java A src/java/org/apache/fop/fonts/GlyphPositioningSubtable.java M src/java/org/apache/fop/fonts/truetype/TTFFile.java M src/java/org/apache/fop/fonts/LazyFont.java A src/java/org/apache/fop/fonts/GlyphPositioning.java A src/java/org/apache/fop/fonts/ArabicScriptProcessor.java A src/java/org/apache/fop/fonts/GlyphSequence.java M src/java/org/apache/fop/fonts/type1/AFMFile.java A src/java/org/apache/fop/fonts/GlyphSubstitutionTable.java M src/java/org/apache/fop/fonts/FontReader.java A src/java/org/apache/fop/fonts/Substitutable.java M src/java/org/apache/fop/fo/FOText.java M src/java/org/apache/fop/fo/Constants.java M src/java/org/apache/fop/fo/extensions/svg/SVGDOMContentHandlerFactory.java M src/java/org/apache/fop/fo/PropertyList.java M src/java/org/apache/fop/fo/FObj.java M src/java/org/apache/fop/fo/flow/table/Table.java M src/java/org/apache/fop/fo/pagination/SimplePageMaster.java M src/java/org/apache/fop/fo/pagination/PageSequence.java M src/java/org/apache/fop/fo/pagination/Region.java M src/java/org/apache/fop/fo/properties/DimensionPropertyMaker.java M src/java/org/apache/fop/fo/properties/CorrespondingPropertyMaker.java M src/java/org/apache/fop/fo/properties/IndentPropertyMaker.java M src/java/org/apache/fop/fo/FOPropertyMapping.java A src/java/org/apache/fop/traits/Direction.java A src/java/org/apache/fop/traits/WritingMode.java M src/java/org/apache/fop/area/BodyRegion.java M src/java/org/apache/fop/area/MainReference.java M src/java/org/apache/fop/area/AreaTreeParser.java M src/java/org/apache/fop/area/AreaTreeModel.java M src/java/org/apache/fop/area/PageViewport.java M src/java/org/apache/fop/area/Page.java M src/java/org/apache/fop/area/inline/WordArea.java M src/java/org/apache/fop/area/inline/TextArea.java M src/java/org/apache/fop/area/inline/Viewport.java M src/java/org/apache/fop/area/Span.java M src/java/org/apache/fop/area/RegionReference.java M src/java/org/apache/fop/area/PageSequence.java M src/java/org/apache/fop/area/Area.java M src/java/org/apache/fop/area/Trait.java M src/java/org/apache/fop/area/RegionViewport.java M src/java/org/apache/fop/area/Block.java M src/java/org/apache/fop/util/CharUtilities.java Jeremias Maerki
Purpose of IFRenderer.TextUtil.combined?
Hi, what was that boolean supposed to do, given that it’s set to false by default, never set to true and results into dead code in renderSpace and renderText? Thanks, Vincent
Re: Purpose of IFRenderer.TextUtil.combined?
Vincent, that's from when I implemented the IF format. I experimented to get the word and letter spaces right. Obviously, that's a left-over by mistake that can be removed now. On 07.07.2010 13:38:40 Vincent Hennebert wrote: Hi, what was that boolean supposed to do, given that it’s set to false by default, never set to true and results into dead code in renderSpace and renderText? Thanks, Vincent Jeremias Maerki
RE: Purpose of IFRenderer.TextUtil.combined?
Last I attempted to build the Trunk I got a ton of warnings, including the Serializable class without serialVersionUID, The field __ is never read locally, and Dead code.. It seems whomever is putting in such code is either using a different compiler, is ignoring the warnings, or has the warnings disabled. I don't know how much the serialization error means. Those other errors are just clutter code (won't crash anything, should cause the compiled jar to be a bit larger than necessary). I've written some clutter code myself. Sometimes it's a method I've removed all reference to but leave it in just in case it is still useful and I want to add a reference from something later. Sometimes it's test code that I've written a different way and left it around in case the other way doesn't come out right. Sometimes it's future code, adding a flag to remind of a feature to be added later.. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Wednesday, July 07, 2010 9:02 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Purpose of IFRenderer.TextUtil.combined? Vincent, that's from when I implemented the IF format. I experimented to get the word and letter spaces right. Obviously, that's a left-over by mistake that can be removed now. On 07.07.2010 13:38:40 Vincent Hennebert wrote: Hi, what was that boolean supposed to do, given that it's set to false by default, never set to true and results into dead code in renderSpace and renderText? Thanks, Vincent Jeremias Maerki
Re: Possible Bug: No control Over Itemized List Marks
On Tue, Jun 29, 2010 at 12:07, Christopher R. Maden cr...@maden.org wrote: Tom Browder wrote: 1. Is this a fop bug? ... Your FO markup is almost certainly requesting the symbol you see. FOP does not make up list markers on its own; it uses the requested symbol. Thanks, Chris. The information in the two docbook books led me to believe it was an implementation issue which I assumed was fop. I found the places to fix it--it looks like a DocBook limitation to me. -Tom
Re: svn commit: r961399
This completes the documentation for the release. Note the following points: Rewrote xdocs/status.xml. Removed all references to the 0.20 versions. Removed all links to 0.94 and earlier. xdocs/upgrading.xml is completely outdated. Do we need a new upgrading document, or shall we delete it? faq id=svg-attribute-required: still applicable? examples.xml: 'Developers will find the first steps to a test suite for all implemented formatting objects and properties in xml-fop/test/xml/'. Is this still the best advertisement for our test suite? resources.xml: Latest supported SVG specification? resources.xml, PDF: All three Adobe links are outdated. PS: Both links are outdated. resources.xml, TIFFRenderer: link outdated. resources.xml, AFP renderer: Does it still make sense to link to this page, since we now have the AFP renderer included? 1.0/pdfx.html, note: Support for PDF/X is no longer new. Reformulate. Please, consider if you want to make some changes or have some comments. Simon On Wed, Jul 07, 2010 at 03:04:02PM -, spepp...@apache.org wrote: Author: spepping Date: Wed Jul 7 15:04:01 2010 New Revision: 961399 URL: http://svn.apache.org/viewvc?rev=961399view=rev Log: Changes to the documentation, partly needed for the new release, partly updates to outdated information -- Simon Pepping home page: http://www.leverkruid.eu
