Re: [VOTE] Merge the Temp_Accessibility Branch Back to Trunk
Vincent Hennebert wrote: Hi, Hi Vincent, Work on PDF accessibility is basically done. There are still some tests to perform and maybe a few tweaks here and there, but the main functionality is in place. Thanks for all your hard work getting this feature debugged and cleaned up. So I’d like to start a vote for merging the branch back to the Trunk: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Accessibility The vote will last the usual 3 days but, since it’s a non-trivial new feature, if any committer would like more time to review it, feel free to say so and we can extend the vote to 1 week. Attached is the diff between the branch and the Trunk, if this is of any help. +1 from me. I've done some local testing with the branch just now and it seems to work, so +1 from me. Chris Thanks, Vincent
Bug report - reading config xml
Hi Everyone,
I think, I have found a bug.
I want to use FOP to convert xsl-fo files into txt files with layout.
I experienced, that the layout is distorted because the max column number is
set to 80 by default. I wanted to change this value using a config xml ( fop -c
cfg.xml),
so I took the example config xml (distribution 0.95, {fop-dir}/conf/fop.xconf).
It contains this section:
renderers
renderer mime=text/plain
pageSize columns=80/
/renderer
/renderers
This would be exactly what I need, and because this section, I think, FOP is
supposed to read this information from the configuration xml and not only to
work with the default value.
The problem is, that the application is not reading this config information
from the config file.
Than I validated the config file I built, and according to the latest .xsd
(http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd,
No 731248),
it is not valid, the pageSize element does not exist.
Can You please advise, how to set default column number to higher or could
anyone please add this functionality/fix this bug?
Thank You
doger
brbrbra
href= http://ad.adverticum.net/b/cl,1,6022,359365,443916/click.prm;
Nokia 5130 Domino csomagban 25 990 Ft helyett 23 391 Ft csak a T-Mobile
Webshopban.
/a
?xml version=1.0?
!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the License); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
!-- $Id: fop.xconf 447325 2006-09-18 08:55:33Z jeremias $ --
!--
This is an example configuration file for FOP.
This file contains the same settings as the default values
and will have no effect if used unchanged.
Relative config url's will be resolved relative to
the location of this file.
--
!-- NOTE: This is the version of the configuration --
fop version=1.0
!-- Base URL for resolving relative URLs --
base./base
!-- Source resolution in dpi (dots/pixels per inch) for determining the size
of pixels in SVG and bitmap images, default: 72dpi --
source-resolution72/source-resolution
!-- Target resolution in dpi (dots/pixels per inch) for specifying the
target resolution for generated bitmaps, default: 72dpi --
target-resolution72/target-resolution
!-- Default page-height and page-width, in case
value is specified as auto --
default-page-settings height=11in width=8.26in/
!-- Information for specific renderers --
!-- Uses renderer mime type for renderers --
renderers
renderer mime=application/pdf
filterList
!-- provides compression using zlib flate (default is on) --
valueflate/value
!-- encodes binary data into printable ascii characters (default off)
This provides about a 4:5 expansion of data size --
!-- valueascii-85/value --
!-- encodes binary data with hex representation (default off)
This filter is not recommended as it doubles the data size --
!-- valueascii-hex/value --
/filterList
fonts
!-- embedded fonts --
!--
This information must exactly match the font specified
in the fo file. Otherwise it will use a default font.
For example,
fo:inline font-family=Arial font-weight=bold font-style=normal
Arial-normal-normal font
/fo:inline
for the font triplet specified by:
font-triplet name=Arial style=normal weight=bold/
If you do not want to embed the font in the pdf document
then do not include the embed-url attribute.
The font will be needed where the document is viewed
for it to be displayed properly.
possible styles: normal | italic | oblique | backslant
possible weights: normal | bold | 100 | 200 | 300 | 400
| 500 | 600 | 700 | 800 | 900
(normal = 400, bold = 700)
--
!--
font metrics-url=arial.xml kerning=yes embed-url=arial.ttf
font-triplet name=Arial style=normal weight=normal/
font-triplet name=ArialMT style=normal weight=normal/
/font
font metrics-url=arialb.xml kerning=yes embed-url=arialb.ttf
font-triplet name=Arial style=normal weight=bold/
font-triplet
Re: [VOTE] Merge the Temp_Accessibility Branch Back to Trunk
Hi Vincent, I've take a look this morning and it looks good from the testing I've done - it really increases the PDF file size though! :). +1 from me. Adrian. Chris Bowditch wrote: Vincent Hennebert wrote: Hi, Hi Vincent, Work on PDF accessibility is basically done. There are still some tests to perform and maybe a few tweaks here and there, but the main functionality is in place. Thanks for all your hard work getting this feature debugged and cleaned up. So I’d like to start a vote for merging the branch back to the Trunk: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Accessibility The vote will last the usual 3 days but, since it’s a non-trivial new feature, if any committer would like more time to review it, feel free to say so and we can extend the vote to 1 week. Attached is the diff between the branch and the Trunk, if this is of any help. +1 from me. I've done some local testing with the branch just now and it seems to work, so +1 from me. Chris Thanks, Vincent
RE: Support for Arabic in FOP
Hi, I cannot sign the license because not all the work is mine. I've uploaded it again here: http://www.hmedia.de/wiki/doku.php?id=forum:foparabic The classes in the intl package are free available in the internet but under other licenses. I think all the changes in the org.apache.fop.* packages are my 'intellectual property'. So I could sign the contributor license for these changes, if needed. But as Jeremias already said, the things I did are not correct (e.g. mirroring in the CTM class or whatever). Maybe its ok to take my stuff as a starting point and implement it in the right way. Good Luck. Sebastian -- View this message in context: http://www.nabble.com/Volunteering-to-work-on-FOP-development-tp25442059p26024361.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: [VOTE] Merge the Temp_Accessibility Branch Back to Trunk
Hi, Just a few precisions: Jeremias Maerki wrote: On 22.10.2009 21:15:40 Simon Pepping wrote: snip/ Can you summarize what the branch tries to achieve? I'll try. In short: it provides the Tagged PDF feature that some people have always wanted. Long story: Without the accessibility/document structure feature, FOP simply produces pages with visual content. Visually impaired people need tools like a screen reader to read document to them. For that the reader needs to know which parts of a page are important and which are not, and in which order the elements should be read. It needs to know that a sentence continues on the next page without stumbling over the page footer in the middle of the sentence. This is something that the branch doesn’t actually do yet... The header/footer will be read at every new page, in the middle of the sentence. I don’t know yet how to fix that, and I’m not sure if that should be done blindly anyway. It could be imagined that in some elaborate layouts the side-regions have content that the author wants to be read aloud. snip/ There's another side-effect to tagged PDF: It allows for better text extraction from the document. PDF even describes ways to make round-trips from XML - PDF - XML - PDF if certain conditions were met. However, we don't do that. Speaking of that, the current code doesn’t insert empty elements (like fo:block/) into the structure tree. The corresponding StructElem object /is/ created, but is not linked to its parent. Actually it’s present in the PDF without being referred to by any other object. I think this is inconsistent, and actually wrong since that would cause a loss of information possibly needed by a round-trip transformation. I’m going to change that. snip/ The vote will last the usual 3 days but, since it???s a non-trivial new feature, if any committer would like more time to review it, feel free to say so and we can extend the vote to 1 week. Can you make that 3 working days? Does that imply you don't work 7 days a week? ;-) Working days are what we usually apply here, don't we? Errr... no. At least it’s just by chance if all the votes I’ve launched so far turned out to last 3 working days. I usually just wait that most active committers have voted. Speaking of working days doesn’t make much sense to me anyway since not all committers work on FOP in their day jobs. Some of them may actually be more active at week-ends. All that said, I’m happy to make the vote last longer as Simon requested. And to ensure that it lasts at least 3 working days from now on. Vincent
Re: [VOTE] Merge the Temp_Accessibility Branch Back to Trunk
On 23.10.2009 13:14:36 Vincent Hennebert wrote: Hi, Just a few precisions: Jeremias Maerki wrote: On 22.10.2009 21:15:40 Simon Pepping wrote: snip/ Can you summarize what the branch tries to achieve? I'll try. In short: it provides the Tagged PDF feature that some people have always wanted. Long story: Without the accessibility/document structure feature, FOP simply produces pages with visual content. Visually impaired people need tools like a screen reader to read document to them. For that the reader needs to know which parts of a page are important and which are not, and in which order the elements should be read. It needs to know that a sentence continues on the next page without stumbling over the page footer in the middle of the sentence. This is something that the branch doesn’t actually do yet... The header/footer will be read at every new page, in the middle of the sentence. I don’t know yet how to fix that, and I’m not sure if that should be done blindly anyway. It could be imagined that in some elaborate layouts the side-regions have content that the author wants to be read aloud. Actually, I believe we already do it quite nicely but that there is a bug in Acrobat's screen reader which doesn't fully rely on the document structure information, but rather reads through the tag order on each page which is not what I would expect. I was just thinking: if PDFBox could be taught to interpret the document structure information and feed the content to FreeTTS, you'd have a nice open source PDF reader. snip/ There's another side-effect to tagged PDF: It allows for better text extraction from the document. PDF even describes ways to make round-trips from XML - PDF - XML - PDF if certain conditions were met. However, we don't do that. Speaking of that, the current code doesn’t insert empty elements (like fo:block/) into the structure tree. The corresponding StructElem object /is/ created, but is not linked to its parent. Actually it’s present in the PDF without being referred to by any other object. I think this is inconsistent, and actually wrong since that would cause a loss of information possibly needed by a round-trip transformation. I’m going to change that. Good catch. snip/ Jeremias Maerki
DO NOT REPLY [Bug 47638] Nested fo:inline with padding raise a NPE
https://issues.apache.org/bugzilla/show_bug.cgi?id=47638 --- Comment #1 from Jonathan Levinson levin...@intersystems.com 2009-10-23 07:12:44 UTC --- Created an attachment (id=24410) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24410) Patch for null pointer exception -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46402] fop crashes for table-omit-header-at-break=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=46402 --- Comment #4 from Jonathan Levinson levin...@intersystems.com 2009-10-23 07:23:28 UTC --- This looks fixed in 0.95. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Bug report - reading config xml
Domján Gergő wrote:
Hi Everyone,
Hi Domjan,
I think, I have found a bug.
I want to use FOP to convert xsl-fo files into txt files with layout.
I experienced, that the layout is distorted because the max column
number is set to 80 by default. I wanted to change this value using a
config xml ( fop -c cfg.xml),
so I took the example config xml (distribution 0.95,
{fop-dir}/conf/fop.xconf).
It contains this section:
renderers
renderer mime=text/plain
pageSize columns=80/
/renderer
/renderers
This would be exactly what I need, and because this section, I think,
FOP is supposed to read this information from the configuration xml and
not only to work with the default value.
The problem is, that the application is not reading this config
information from the config file.
That's right. It is not sufficient to simply add new XML elements into
the config and hope that FOP somehow applies this value to the output.
You have to make FOP read the element by changing the code. This is done
fairly eaily in the configure method of class TXTRendererConfigurator.
Then you have to make sure the value extracted there is applied to the
output which in some cases is less trivial.
Than I validated the config file I built, and according to the latest
.xsd
(http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd,
No 731248),
it is not valid, the pageSize element does not exist.
Can You please advise, how to set default column number to higher or
could anyone please add this functionality/fix this bug?
Chris
Thank You
doger
Nokia 5130 Domino csomagban 25 990 Ft helyett 23 391 Ft csak a T-Mobile
Webshopban. http://ad.adverticum.net/b/cl,1,6022,359365,443916/click.prm
DO NOT REPLY [Bug 39443] Long tables stop spanning in multiple columns after first page
https://issues.apache.org/bugzilla/show_bug.cgi?id=39443 Sergey ts...@mail.ru changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ts...@mail.ru Version|0.92|0.95 Resolution|FIXED | --- Comment #4 from Sergey ts...@mail.ru 2009-10-23 07:51:30 UTC --- reproduced on Apache FOP Version 0.95 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Re: Bug report - reading config xml
Hi Chris,
Thank You for Your answer.
I would like to make clear, that it was not me, who added this pageSize
element arbitrarily to the config file, it was in the sample config xml I
downloaded with the FOP package 0.95 from the Apache FOP website.
So it is definitely a mistake.
There is two solution for the problem:
1. to delete the pageSize element from the sample config xml on the Apache
web site
2. to add this functionality really to the FOP application.
As You wrote, the second is also not a big deal (or: fairly easy), to
someone, who has the development environment for Java installed and who has
some experience with Java programming.
Sadly, I have none of them, so I was wondering, if I could ask someone from the
Apache FOP community and who would be so kind to do this (maybe not only) for
me.
Please please please
Thank You in advance
Gergo
Chris Bowditch bowditch_ch...@hotmail.com írta:
Domján Gergő wrote:
Hi Everyone,
Hi Domjan,
I think, I have found a bug.
I want to use FOP to convert xsl-fo files into txt files with layout.
I experienced, that the layout is distorted because the max column
number is set to 80 by default. I wanted to change this value using a
config xml ( fop -c cfg.xml),
so I took the example config xml (distribution 0.95,
{fop-dir}/conf/fop.xconf).
It contains this section:
renderers
renderer mime=text/plain
pageSize columns=80/
/renderer
/renderers
This would be exactly what I need, and because this section, I think,
FOP is supposed to read this information from the configuration xml and
not only to work with the default value.
The problem is, that the application is not reading this config
information from the config file.
That's right. It is not sufficient to simply add new XML elements into
the config and hope that FOP somehow applies this value to the output.
You have to make FOP read the element by changing the code. This is done
fairly eaily in the configure method of class TXTRendererConfigurator.
Then you have to make sure the value extracted there is applied to the
output which in some cases is less trivial.
Than I validated the config file I built, and according to the latest
.xsd
(http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/foschema/fop-configuration.xsd,
No 731248),
it is not valid, the pageSize element does not exist.
Can You please advise, how to set default column number to higher or
could anyone please add this functionality/fix this bug?
Chris
Thank You
doger
Nokia 5130 Domino csomagban 25 990 Ft helyett 23 391 Ft csak a T-Mobile
Webshopban. http://ad.adverticum.net/b/cl,1,6022,359365,443916/click.prm;
brbrbra
href= http://ad.adverticum.net/b/cl,1,6022,359365,443916/click.prm;
Nokia 5130 Domino csomagban 25 990 Ft helyett 23 391 Ft csak a T-Mobile
Webshopban.
/a
Inserting Empty Elements Into the Structure Tree [was: Re: [VOTE] Merge the Temp_Accessibility Branch Back to Trunk]
Vincent Hennebert wrote: Hi, snip/ There's another side-effect to tagged PDF: It allows for better text extraction from the document. PDF even describes ways to make round-trips from XML - PDF - XML - PDF if certain conditions were met. However, we don't do that. Speaking of that, the current code doesn’t insert empty elements (like fo:block/) into the structure tree. The corresponding StructElem object /is/ created, but is not linked to its parent. Actually it’s present in the PDF without being referred to by any other object. I think this is inconsistent, and actually wrong since that would cause a loss of information possibly needed by a round-trip transformation. I’m going to change that. I mean, /at some point/ I’m going to change that... This is not as easily done as it is said. Take the following example: fo:block Before the empty block. fo:block/ After the empty block. /fo:block What basically happens currently is that two text drawing requests are made to the PDF renderer. The renderer creates the appropriate PDF stream and registers the pieces of text as children of the structure element corresponding to the outer block. But nothing happens regarding the inner empty block, since obviously there’s nothing to do. The structure element for the inner empty block can’t be added to the outer block’s children at creation time, otherwise the logical order wouldn’t be followed. From the quick look I had this is a fundamental limitation of the current approach. There’s no way to know at which place an empty element must be inserted into the children list of its parent. The only way to solve this issue probably is to integrate the handling of the logical structure into the whole processing chain, passing the suitable information from the FO tree to the layout engine to the area tree to the renderer. Probably something that should have been done from the beginning but this is all but trivial. Vincent
Re: [VOTE] Merge the Temp_Accessibility Branch Back to Trunk
On Thu, Oct 22, 2009 at 10:36:47PM +0200, Jeremias Maerki wrote: On 22.10.2009 21:15:40 Simon Pepping wrote: On Thu, Oct 22, 2009 at 05:12:00PM +0100, Vincent Hennebert wrote: Hi, Work on PDF accessibility is basically done. There are still some tests to perform and maybe a few tweaks here and there, but the main functionality is in place. So I???d like to start a vote for merging the branch back to the Trunk: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Accessibility Can you summarize what the branch tries to achieve? I'll try. In short: it provides the Tagged PDF feature that some people have always wanted. Thanks. That was quite clear. I am not in a position to judge the quality of the implementation. I welcome this addition to FOP. I vote +1 to the merger of the Temp_Accessibility branch into trunk. Simon -- Simon Pepping home page: http://www.leverkruid.eu
