[Bug 54037] New: Issue a warning when accessibility is enabled and language information is missing
https://issues.apache.org/bugzilla/show_bug.cgi?id=54037 Priority: P2 Bug ID: 54037 Assignee: fop-dev@xmlgraphics.apache.org Summary: Issue a warning when accessibility is enabled and language information is missing Severity: normal Classification: Unclassified OS: All Reporter: vhenneb...@gmail.com Hardware: All Status: NEW Version: all Component: pdf Product: Fop To follow PDF/A compatibility, FOP stores the default value of x-unknown in the Lang entry in the document catalog. That value is overridden if a language is set on the fo:root element in the source document, but not in other cases. If no language is defined on descendant elements, then a screen reader will fall back to the entry in the document catalog and may read it out loud, resulting into a disconcerting aural rendering for the user. To reduce that risk it would be good to issue a warning whenever an element (block of text or image with an alternate text) is missing language information. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 54037] Issue a warning when accessibility is enabled and language information is missing
https://issues.apache.org/bugzilla/show_bug.cgi?id=54037 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vincent Hennebert vhenneb...@gmail.com --- Fix in rev. 1400890: http://svn.apache.org/viewvc?rev=1400890view=rev -- You are receiving this mail because: You are the assignee for the bug.
updating fop-pdf-images
Now that XGC 1.5 and FOP 1.1 are out the door, it would be nice if someone would update fop-pdf-images to use these. I will do it if nobody else will, however, I haven't built or used that extension before, so I'm sure someone else could do it better and faster. Volunteer anyone?
[Bug 54038] New: Add PDF/A-2 output option
https://issues.apache.org/bugzilla/show_bug.cgi?id=54038 Priority: P2 Bug ID: 54038 Assignee: fop-dev@xmlgraphics.apache.org Summary: Add PDF/A-2 output option Severity: normal Classification: Unclassified OS: Linux Reporter: vhenneb...@gmail.com Hardware: PC Status: NEW Version: all Component: pdf Product: Fop In the context of FOP, this would mainly allow to produce PDF/A compliant documents that include transparency. -- You are receiving this mail because: You are the assignee for the bug.
Re: [Vote] for the merge of Temp_RoundedCorners
Hi Glenn, I have just committed to Temp_RoundedCorners to address some of the concerns raised. My preference would be to provide both the CSS3 named properties and also writing system relative properties, giving the user the preference of which to use. But I would suggest using the same pattern as CSS3 for property names for these latter: border-top-left-radius border-top-right-radius border-bottom-right-radius border-bottom-left-radius border-before-start-radius border-before-end-radius border-after-start-radius border-after-end-radius I have now implemented border properties of the form border-before-start-radius, that take one or two values, in line with the CSS3 recommendation. However, I have not been able as yet to implement properties for the absolute properties (border-top-left-radius, etc). I am unable to prove concretely that the property resolution system can or cannot support my requirements here, but either way I have decided to put this requirement on hold for now. The omission of these properties will not affect backwards compatibility going forward and so I do not personally consider it to be a show stopper. it would also be useful to support the border-radius shortcut from CSS3 (mapping to the above CSS3 longhand flavors) This was done previously if we accept that the second value refers to the block progression direction and not the absolute top-to-bottom direction. I have updated the example fo and the CMS to reflect these changes. If you are happy with the change I can proceed with the merge. Thanks, Peter
Re: [Vote] for the merge of Temp_RoundedCorners
Hi Jeremias, I have updated the CMS to document that there are limitations with tables. I have suggested that setting the 'border-collapse' property on tables to 'separate' will allow the support of rounded corners on tables. I am currently fighting with FOPropertyMapping to support the absolute properties and I am not having much luck. Thanks again for your help with this feature! Peter On Sun, Oct 14, 2012 at 10:56 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: I took a peek since I helped with the branch in the beginning. Nice job over all!!! Good looking borders! I agree with Glenn that the extension should be aligned with CSS3 as closely as possible. In the usual XSL manner there should ideally be both relative (start, end...) and absolute (top, left...) properties. While there seem to be unit tests for the generation of painting operators there are no layout engine tests that verify area tree generation as well as area tree and IF parsing/round-trips. Also I haven't found any mention in the docs or the demo file that rounded borders on tables are not implemented, yet. I found that out the hard way. Seems like border radius information is lost during border collapse processing. However, that should be easy to fix and is probably a matter of adding a few lines to CollapsingBorderModelEyeCatching.java. Some layout engine tests will help here. +0.5 as the current state goes. +1 if CSS3 alignment is achieved and there are a few layout engine tests (at least one for fo:block and one for fo:inline) checking the decoding of the enhanced border function and the AT/IF round-trip. The missing table border support is surely not blocking. Jeremias Maerki On 12.10.2012 11:40:19 Peter Hancock wrote: Hi, Luis Benardo and Myself have just done some clean up to the branch Temp_RoundedCorners. This branch implements support for 'fox' extension properties for specifying borders with rounded corners. Please refer to [1] and [2] for details. There is an example fo [3] that demonstrates the feature. Currently we are supporting: PDF, PS and AFP outputs 'border-style' property with values of 'solid', 'none', 'hidden' and, to a limited degree, 'dashed' I would like to start a vote to merge feature branch to trunk, with my +1. Thanks, Peter [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
Re: [Vote] for the merge of Temp_RoundedCorners
Hi Vincent,
In the last commit to Temp_RoundedCorners I have addressed all your
points, except:
• o.a.f.render.intermediate.BorderPainterTestCase
the generics don’t seem necessary and could be removed altogether
I would like to improve that little micro-framework to eliminate the
need for generics (and the cast I had to do!) but I think it serves
it's purpose for now.
Thanks,
Pete
On Fri, Oct 19, 2012 at 4:43 PM, Vincent Hennebert vhenneb...@gmail.com wrote:
+1
Having the ‘absolute’ versions of the properties would be nice but this
is not IMO a blocker requirement for the merge of this work.
Here are a few comments based on a quick look at the branch:
• o.a.f.fo.Constants
PR_X_BORDER_START_RADIUS_START
PR_X_BORDER_START_RADIUS_END
PR_X_BORDER_END_RADIUS_START
PR_X_BORDER_END_RADIUS_END
Shouldn’t it be
PR_X_BORDER_START_RADIUS_BEFORE
PR_X_BORDER_START_RADIUS_AFTER
PR_X_BORDER_END_RADIUS_BEFORE
PR_X_BORDER_END_RADIUS_AFTER
?
• o.a.f.fo.properties.BoxCornerPropShorthandParser
some glitches in the javadoc for convertValueForProperty
• o.a.f.fo.properties.CommonBorderPaddingBackground
there’s a commented out ‘if (style != Constants.EN_NONE) {’? Is that
left-overs from debugging that can be removed?
• o.a.f.layoutmgr.TraitSetter
line ~100: it’s a shame to re-introduce Hungarian notation
• o.a.f.render.intermediate.BorderPainter
left-over ‘TODO remove before integration’?
drawBorderSegment: don’t you want to use Math.round instead of
directly casting to int, for better precision?
• o.a.f.render.intermediate.BorderPainterTestCase
the generics don’t seem necessary and could be removed altogether
• o.a.f.render.pdf.PDFPainterTestCase,
o.a.f.render.ps.PSPainterTestCase
the ‘// mock’ comments are hardly helpful and could be removed; the
variables could instead be renamed into something that starts with
‘mock’ so that we know what is what later in the code.
The try...catch should really be removed: if an exception occurs
during the test it will be swallowed (along with its stack trace) by
the catch and replaced with an unhelpful AssertionError with no stack
trace.
Thanks,
Vincent
On 12/10/12 10:40, Peter Hancock wrote:
Hi,
Luis Benardo and Myself have just done some clean up to the branch
Temp_RoundedCorners. This branch implements support for 'fox'
extension properties for specifying borders with rounded corners.
Please refer to [1] and [2] for details.
There is an example fo [3] that demonstrates the feature.
Currently we are supporting:
PDF, PS and AFP outputs
'border-style' property with values of 'solid', 'none', 'hidden'
and, to a limited degree, 'dashed'
I would like to start a vote to merge feature branch to trunk, with my +1.
Thanks,
Peter
[1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
[2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
[2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
[Bug 53912] PDF/A-1b compliance is broken in 1.1RC1
https://issues.apache.org/bugzilla/show_bug.cgi?id=53912 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Blocks||54038 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 54038] Add PDF/A-2 output option
https://issues.apache.org/bugzilla/show_bug.cgi?id=54038 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Depends on||53912 --- Comment #1 from Vincent Hennebert vhenneb...@gmail.com --- Option added in rev. 1400919: http://svn.apache.org/viewvc?rev=1400919view=rev I'm leaving this bug open for now as it needs to be checked with some PDF/A-2 validator. -- You are receiving this mail because: You are the assignee for the bug.
Re: [Vote] for the merge of Temp_RoundedCorners
thanks, i'm good to go then, so you have my +1 On Mon, Oct 22, 2012 at 11:04 PM, Peter Hancock peter.hanc...@gmail.comwrote: Hi Glenn, I have just committed to Temp_RoundedCorners to address some of the concerns raised. My preference would be to provide both the CSS3 named properties and also writing system relative properties, giving the user the preference of which to use. But I would suggest using the same pattern as CSS3 for property names for these latter: border-top-left-radius border-top-right-radius border-bottom-right-radius border-bottom-left-radius border-before-start-radius border-before-end-radius border-after-start-radius border-after-end-radius I have now implemented border properties of the form border-before-start-radius, that take one or two values, in line with the CSS3 recommendation. However, I have not been able as yet to implement properties for the absolute properties (border-top-left-radius, etc). I am unable to prove concretely that the property resolution system can or cannot support my requirements here, but either way I have decided to put this requirement on hold for now. The omission of these properties will not affect backwards compatibility going forward and so I do not personally consider it to be a show stopper. it would also be useful to support the border-radius shortcut from CSS3 (mapping to the above CSS3 longhand flavors) This was done previously if we accept that the second value refers to the block progression direction and not the absolute top-to-bottom direction. I have updated the example fo and the CMS to reflect these changes. If you are happy with the change I can proceed with the merge. Thanks, Peter
fop bz versions
I added a new version for 1.1, and renamed 1.1dev to trunk.
