[jira] [Commented] (FOP-2897) Out of memory when loading fonts on Mac - instead it should report font too large and continue
[
https://issues.apache.org/jira/browse/FOP-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556213#comment-17556213
]
Dan Caprioara commented on FOP-2897:
Sure, but in our case FOP is part of an application and it runs on somebody
else machine, so it is not an option to delegate this to the end user.
> Out of memory when loading fonts on Mac - instead it should report font too
> large and continue
> --
>
> Key: FOP-2897
> URL: https://issues.apache.org/jira/browse/FOP-2897
> Project: FOP
> Issue Type: Bug
>Reporter: Dan Caprioara
>Priority: Major
>
> The FontInfoFinder class collects all the fonts from the system. On Mac there
> are huge font files containing icons. This makes FOP break with
> OutOfMemoryError.
> Probably it should show an warning and throw an IOException instead of OOM
> (IOException does not break the entire processing, just skips the current
> font loading, in this way next fonts can be loaded).
> There are two places in the FontInfoFinder class where the OOM should be
> catched:
> {code:java}
> try {
>TTFFile ttf = new TTFFile(false, false);
>FontFileReader reader = new FontFileReader(in);
>ttcNames = ttf.getTTCnames(reader);
> } catch (OutOfMemoryError oom) {
>handleOOM(fontURI);
> }
> {code}
> {code:java}
> try {
>OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
> EmbeddingMode.AUTO,
> EncodingMode.AUTO, useKerning, useAdvanced,
> resourceResolver, false, false);
>customFont = ttfLoader.getFont();
>if (this.eventListener != null) {
> customFont.setEventListener(this.eventListener);
>}
> } catch(OutOfMemoryError e) {
>handleOOM(fontURI);
> }
> {code}
> And the handling:
> {code:java}
> private void handleOOM(URI fontURI) throws IOException {
> String sizeMsg = "";
> if ("file".equals(fontURI.getScheme())) {
> sizeMsg = "The font file size was: " + new
> File(fontURI).length() + " bytes";
> }
> throw new IOException(
> "Font is too large. " + sizeMsg);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FOP-2960) [PATCH] Soft-Hyphen on Hyphenated words.
[
https://issues.apache.org/jira/browse/FOP-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387155#comment-17387155
]
Dan Caprioara commented on FOP-2960:
There might be problems with this patch.
Having the following text, with hyphens auto, and a small size for the
container:
{code}
supercalifragilisticexpialidolcius.supercalifragilisticexpialidolcius
{code}
The result is:
{code}
supercalifragilisticexpiali-
dolcius.supercalifragilisticexpialidolcius
{code}
Note that the second {{supercalifragilisticexpialidolcius}} is bleeding to the
right side of the page and is not segmented anymore. Since the hyphenation is
on "auto", not "manual", I expect the breaking algorithm to take into account
both normal hyphenation points and the ones indicated by the soft hyphens.
> [PATCH] Soft-Hyphen on Hyphenated words.
>
>
> Key: FOP-2960
> URL: https://issues.apache.org/jira/browse/FOP-2960
> Project: FOP
> Issue Type: Bug
> Components: layout/line
>Affects Versions: 1.1
>Reporter: Juan
>Assignee: Chris Bowditch
>Priority: Minor
> Labels: hyphenation, soft-hyphen
> Fix For: 2.6
>
> Attachments: fix-soft-hyphens-on-hyphenated-words.patch
>
>
> When hyphenate="true", a word containing a soft-hyphen ( \u00ad ) will break
> line at the position given by the higher level word hyphenation, ignoring the
> pre-hyphenation made by applying soft-hyphens.
>
> About the patch:
> Fixes the disabled test "block_shy_linebreaking_hyph.xml" wich is related to
> FOP-2466 by disabling the higher level hyphenation when a word contains a
> soft-hyphen.
> Note that at this part of the code, the original word has been already
> divided into 2 words by the soft-hyphen, to workaround this, we look at
> current and previous Glyphs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FOP-2976) Some Linux readers fail to load the PDF because of a missmatch between the declared PDF version and the actual set of PDF features (1.4 and cross reference streams)
Dan Caprioara created FOP-2976:
--
Summary: Some Linux readers fail to load the PDF because of a
missmatch between the declared PDF version and the actual set of PDF features
(1.4 and cross reference streams)
Key: FOP-2976
URL: https://issues.apache.org/jira/browse/FOP-2976
Project: FOP
Issue Type: Bug
Components: renderer/pdf
Affects Versions: 2.5
Reporter: Dan Caprioara
Some Linux readers fail loading the PDFs produced by FOP. These have the
version 1.4 by default. The PDF contains cross reference streams, which are
defined in PDF 1.5.
The fix would be CrossReferenceStream to increment the version of the PDF
document to 1.5.
The JavaDoc from this class:
{quote}A cross-reference stream, as described in Section 3.4.7 of the PDF 1.5
Reference.
{quote}
A fix in the constructor of \{{CrossReferenceStream }}:
{code:java}
document.setPDFVersion(Version.V1_5);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FOP-2959) Using fo:retrieve-marker in an artifact (static content from header) breaks accesibility for the next page
Dan Caprioara created FOP-2959:
--
Summary: Using fo:retrieve-marker in an artifact (static content
from header) breaks accesibility for the next page
Key: FOP-2959
URL: https://issues.apache.org/jira/browse/FOP-2959
Project: FOP
Issue Type: Bug
Components: renderer/pdf
Affects Versions: 2.4, 2.5
Reporter: Dan Caprioara
Using a fo:retrieve-marker in a header static content, that is marked with role
artifact breaks the accessibility tags structure tree for the next pages.
{code:xml}
Header
{code}
*The cause:*
The class org.apache.fop.accessibility.fo.FO2StructureTreeConverter switches
the current FOEventHandler (converter) to one that "swallows" all events each
time an artifact is found, and restores the initial converter after the
artifact ends.But this gets into conflict with the retrieve markers. The
retrieve marker restore state event is processed asynchronous, just before the
current page is finished, and restores the FOEventHandler to the one it was
available when the start retrieve marker was emmited (in our case the
"swallower", because the retrieve marker was in an artifact). The result is
that the "swallower" is the current FOEventHandler for the next page.
*The fix:*
The fix is to restore the initial handler each time the page ends:
At the end of the method:
org.apache.fop.accessibility.fo.FO2StructureTreeConverter.endPageSequence(PageSequence)
add:
{code:java}
if (converter == eventSwallower) {
converter = structureTreeEventTrigger;
converters.clear();
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FOP-2938) Incomplete TTF subset files for mutibyte fonts - incomplete mapping between CIDs and codepoints when having two codepoints associated to the same glyph
[ https://issues.apache.org/jira/browse/FOP-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Caprioara updated FOP-2938: --- Summary: Incomplete TTF subset files for mutibyte fonts - incomplete mapping between CIDs and codepoints when having two codepoints associated to the same glyph (was: Incomplete TTF subset files - incomplete mapping between CIDs and codepoints when having two codepoints associated to the same glyph) > Incomplete TTF subset files for mutibyte fonts - incomplete mapping between > CIDs and codepoints when having two codepoints associated to the same glyph > --- > > Key: FOP-2938 > URL: https://issues.apache.org/jira/browse/FOP-2938 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.5 >Reporter: Dan Caprioara >Priority: Major > Attachments: CIDFonts Subset Architectural Problem.png > > > A generic problem appears for MultiByte CID fonts. > Because of a limitation of the CIDSubset implemenatation, once a glyph has > been used for a code point, next usages of the same glyph for other > codepoints are discarded. This results in incomplete tables in the TTF sub > set file. The structures from CIDSubset class are maps, limiting > expressiveness. > > In the next diagram I used hyphens and soft hyphens, just as an example, any > text with two different characters that map to the same glyph is affected. > See this attached sketch for details: > !CIDFonts Subset Architectural Problem.png! > The solution would be to avoid usage of hash maps, and create some > associative lists (currently the uniqueness of the keys breaks things). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FOP-2938) Incomplete TTF subset files - incomplete mapping between CIDs and codepoints when having two codepoints associated to the same glyph
Dan Caprioara created FOP-2938: -- Summary: Incomplete TTF subset files - incomplete mapping between CIDs and codepoints when having two codepoints associated to the same glyph Key: FOP-2938 URL: https://issues.apache.org/jira/browse/FOP-2938 Project: FOP Issue Type: Bug Components: font/opentype Affects Versions: 2.5 Reporter: Dan Caprioara Attachments: CIDFonts Subset Architectural Problem.png A generic problem appears for MultiByte CID fonts. Because of a limitation of the CIDSubset implemenatation, once a glyph has been used for a code point, next usages of the same glyph for other codepoints are discarded. This results in incomplete tables in the TTF sub set file. The structures from CIDSubset class are maps, limiting expressiveness. In the next diagram I used hyphens and soft hyphens, just as an example, any text with two different characters that map to the same glyph is affected. See this attached sketch for details: !CIDFonts Subset Architectural Problem.png! The solution would be to avoid usage of hash maps, and create some associative lists (currently the uniqueness of the keys breaks things). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FOP-2880) [PATCH] Hyphenated words are not searchable in readers (when accessibilty is turned on)
[
https://issues.apache.org/jira/browse/FOP-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110016#comment-17110016
]
Dan Caprioara commented on FOP-2880:
Yes, it is a hack. How can we proceed further to get the glyphlist.xml and
encoding.xml updated?
> [PATCH] Hyphenated words are not searchable in readers (when accessibilty is
> turned on)
> ---
>
> Key: FOP-2880
> URL: https://issues.apache.org/jira/browse/FOP-2880
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The hyphenated words are rendered by FOP using the hard hyphen character.
> This contradicts the PDF specification, where in section:
> 14.8.2.2.3 Incidental Artifacts
> clearly states that the SHY soft hyphen U+00AD character should be used.
> The effect is that the hyphenated words are not searchable, and the
> copy/paste feature includes also the hard hyphens, instead of removing them
> and joining the words pieces together.
> Here is a small patch that can be applied on the FOP core project in order to
> fix this - this is more like a proof of concept, the real fix would be to
> change the default hyphenation character * in the FOProppertyMapping and to
> change the font mappings: to remove the replacement of the SHY with the
> HYPHEN, see the org.apache.fop.fonts.CodePointMapping.encStandardEncoding,
> and org.apache.fop.fonts.CodePointMapping.encISOLatin1Encoding
> {code}
>0xad, 0x002D, // hyphen
>0xad, 0x00AD, // hyphen
> {code}
> The patch:
> {code}
> Index: src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> ===
> --- src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> (revision 191037)
> +++ src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> (working copy)
> @@ -15,7 +15,7 @@
> * limitations under the License.
> */
>
> -/* $Id$ */
> +/* $Id: CommonHyphenation.java 1610839 2014-07-15 20:25:58Z vhennebert $ */
>
> package org.apache.fop.fo.properties;
>
> @@ -184,6 +184,16 @@
> */
> public int getHyphIPD(org.apache.fop.fonts.Font font) {
> char hyphChar = getHyphChar(font);
> +
> +if (hyphChar == '\u00ad') {
> + // Bizarre fix, defining the SHY as default hyphenation character
> in the FOPropertyMapping, leads
> + // to hard hyphens not selectable in the PDF reader.
> + //
> + // Mapping also the hard hyphen makes the character selectable!
> + font.mapChar('\u002d');
> +}
> +
> +
> return font.getCharWidth(hyphChar);
> }
>
> Index: src/main/java/org/apache/fop/fo/FOPropertyMapping.java
> ===
> --- src/main/java/org/apache/fop/fo/FOPropertyMapping.java(revision
> 190759)
> +++ src/main/java/org/apache/fop/fo/FOPropertyMapping.java(working copy)
> @@ -1106,7 +1106,10 @@
> // hyphenation-character
> m = new CharacterProperty.Maker(PR_HYPHENATION_CHARACTER);
> m.setInherited(true);
> -m.setDefault("-");
> +//
> +// m.setDefault("-");
> +m.setDefault("\u00ad");
> +
> addPropertyMaker("hyphenation-character", m);
>
> // hyphenation-push-character-count
> Index: src/main/java/org/apache/fop/render/pdf/PDFPainter.java
> ===
> --- src/main/java/org/apache/fop/render/pdf/PDFPainter.java (revision
> 190759)
> +++ src/main/java/org/apache/fop/render/pdf/PDFPainter.java (working copy)
> @@ -420,7 +420,8 @@
> PDFStructElem structElem = (PDFStructElem)
> getContext().getStructureTreeElement();
> languageAvailabilityChecker.checkLanguageAvailability(text);
> MarkedContentInfo mci =
> logicalStructureHandler.addTextContentItem(structElem);
> -String actualText = getContext().isHyphenated() ?
> text.substring(0, text.length() - 1) : null;
> +//String actualText = getContext().isHyphenated() ?
> text.substring(0, text.length() - 1) : null;
> +String actualText = null;
> generator.endTextObject();
> generator.updateColor(state.getTextColor(), true, null);
> generator.beginTextObject(mci.tag, mci.mcid, actualText);
> @@ -490,6 +491,15 @@
> float glyphAdjust = 0;
> if (font.hasCodePoint(orgChar)) {
> ch = font.mapCodePoint(orgChar);
> + if (orgChar ==
> '\u00ad' && ch
[jira] [Comment Edited] (FOP-1776) NPE caused by nested empty fo:inline with id
[
https://issues.apache.org/jira/browse/FOP-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050196#comment-17050196
]
Dan Caprioara edited comment on FOP-1776 at 3/3/20 1:33 PM:
I have the same situation, I added a not null condition on the prevLM and it
works fine now. I see no extra warning messages in the console.
{code}
if (currLM != prevLM || !oldListIterator.hasNext()) {
if (oldListIterator.hasNext()) {
returnedList.addAll(
prevLM.getChangedKnuthElements(
oldList.subList(fromIndex,
oldListIterator.previousIndex()),
alignment, depth));
prevLM = currLM;
fromIndex = oldListIterator.previousIndex();
} else if (currLM == prevLM) {
// NULL CHECK
if(prevLM != null) {
returnedList.addAll(
prevLM.getChangedKnuthElements(
oldList.subList(fromIndex, oldList.size()),
alignment, depth));
}
} else {
returnedList.addAll(
prevLM.getChangedKnuthElements(
oldList.subList(fromIndex,
oldListIterator.previousIndex()),
alignment, depth));
if (currLM != null) {
returnedList.addAll(
currLM.getChangedKnuthElements(
oldList.subList(oldListIterator.previousIndex(),
oldList.size()),
alignment, depth));
}
}
}
{code}
was (Author: dc33):
I have the same situation, I added a not null condition on the prevLM and it
works fine now. This fix should be in FOP.
> NPE caused by nested empty fo:inline with id
>
>
> Key: FOP-1776
> URL: https://issues.apache.org/jira/browse/FOP-1776
> Project: FOP
> Issue Type: Bug
> Components: layout/inline
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Mathieu Malaterre
>Priority: Major
> Attachments: _test.fo, anchor.id.patch, test2.fo
>
>
> Here is my input docbook file:
>
> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; []>
>
>
> title
>
>
> The id="example.anchor.1"/>anchor element is empty and
> contributes
> nothing to the flow of the content in which it occurs. It is only useful
> as a target.
>
>
>
>
> which I process with:
> /usr/bin/xsltproc --stringparam fop1.extensions 1 --stringparam
> ulink.show 0 --xinclude -o test2.fo
> /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl test2.xml
> and lead to:
> $ ./fop test2.fo test2.pdf
> Feb 17, 2010 2:52:18 PM org.apache.fop.apps.FOURIResolver resolve
> SEVERE: Error with opening URL
> 'http://docbook.sourceforge.net/release/images/draft.png': Network is
> unreachable
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:9588)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:10285)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:10980)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:11672)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:12361)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:13050)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:13736)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
> http://docbook.sourceforge.net/release/images/draft.png. (See position
> 2:14427)
> Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener
> processEvent
> SEVERE: Image not found. URI:
>
[jira] [Commented] (FOP-1776) NPE caused by nested empty fo:inline with id
[ https://issues.apache.org/jira/browse/FOP-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050196#comment-17050196 ] Dan Caprioara commented on FOP-1776: I have the same situation, I added a not null condition on the prevLM and it works fine now. This fix should be in FOP. > NPE caused by nested empty fo:inline with id > > > Key: FOP-1776 > URL: https://issues.apache.org/jira/browse/FOP-1776 > Project: FOP > Issue Type: Bug > Components: layout/inline >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Mathieu Malaterre >Priority: Major > Attachments: _test.fo, anchor.id.patch, test2.fo > > > Here is my input docbook file: > > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; []> > > > title > > > The id="example.anchor.1"/>anchor element is empty and > contributes > nothing to the flow of the content in which it occurs. It is only useful > as a target. > > > > > which I process with: > /usr/bin/xsltproc --stringparam fop1.extensions 1 --stringparam > ulink.show 0 --xinclude -o test2.fo > /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl test2.xml > and lead to: > $ ./fop test2.fo test2.pdf > Feb 17, 2010 2:52:18 PM org.apache.fop.apps.FOURIResolver resolve > SEVERE: Error with opening URL > 'http://docbook.sourceforge.net/release/images/draft.png': Network is > unreachable > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:9588) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:10285) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:10980) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:11672) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:12361) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:13050) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:13736) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:14427) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:15118) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:15806) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:16496) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:17186) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:17873) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:18563) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:19253) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position > 2:19940) > Feb 17, 2010 2:52:18 PM org.apache.fop.events.LoggingEventListener > processEvent > SEVERE: Image not found. URI: > http://docbook.sourceforge.net/release/images/draft.png. (See position >
[jira] [Commented] (FOP-2168) The ANT task "org.apache.fop.tools.anttasks.Fop" never throws a build exception
[ https://issues.apache.org/jira/browse/FOP-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997083#comment-16997083 ] Dan Caprioara commented on FOP-2168: Any progress on this? > The ANT task "org.apache.fop.tools.anttasks.Fop" never throws a build > exception > --- > > Key: FOP-2168 > URL: https://issues.apache.org/jira/browse/FOP-2168 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: trunk > Environment: Operating System: > Platform: PC >Reporter: Radu Coravu > Attachments: c1000-031-Exam-Dumps-NewYear-2019.pdf > > > A concrete example, the DITA OT project uses a series of ANT build files to > publish DITA to PDF. > The Apache FOP task "org.apache.fop.tools.anttasks.Fop" is used for this. > If the task fails (for example the PDF is opened in another application or > the XSL-FO file has severe validation problems) it should throw an ANT > BuildException because there is no need to continue the entire ANT build as > if nothing happened. > Instead, the method > "org.apache.fop.tools.anttasks.FOPTaskStarter.render(File, File, String)" > catches all exceptions and just logs them in the console. > This means that it is possible that ANT finishes with a "Build succesfull" > message and in fact the PDF was not produced at all. > Maybe you should add a "failonerror" attribute to the task and have it fail > by default when an error is encountered. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-2897) Out of memory when loading fonts on Mac - instead it should report font too large and continue
[
https://issues.apache.org/jira/browse/FOP-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2897:
---
Description:
The FontInfoFinder class collects all the fonts from the system. On Mac there
are huge font files containing icons. This makes FOP break with
OutOfMemoryError.
Probably it should show an warning and throw an IOException instead of OOM
(IOException does not break the entire processing, just skips the current font
loading, in this way next fonts can be loaded).
There are two places in the FontInfoFinder class where the OOM should be
catched:
{code:java}
try {
TTFFile ttf = new TTFFile(false, false);
FontFileReader reader = new FontFileReader(in);
ttcNames = ttf.getTTCnames(reader);
} catch (OutOfMemoryError oom) {
handleOOM(fontURI);
}
{code}
{code:java}
try {
OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
EmbeddingMode.AUTO,
EncodingMode.AUTO, useKerning, useAdvanced,
resourceResolver, false, false);
customFont = ttfLoader.getFont();
if (this.eventListener != null) {
customFont.setEventListener(this.eventListener);
}
} catch(OutOfMemoryError e) {
handleOOM(fontURI);
}
{code}
And the handling:
{code:java}
private void handleOOM(URI fontURI) throws IOException {
String sizeMsg = "";
if ("file".equals(fontURI.getScheme())) {
sizeMsg = "The font file size was: " + new
File(fontURI).length() + " bytes";
}
throw new IOException(
"Font is too large. " + sizeMsg);
}
{code}
was:
The FontInfoFinder class collects all the fonts from the system. On Mac there
are huge font files containing icons. This makes FOP break with
OutOfMemoryError.
Probably it should show an warning and throw an IOException instead of OOM. In
this way next fonts can be loaded.
There are two places in the FontInfoFinder class where the OOM should be
catched:
{code:java}
try {
TTFFile ttf = new TTFFile(false, false);
FontFileReader reader = new FontFileReader(in);
ttcNames = ttf.getTTCnames(reader);
} catch (OutOfMemoryError oom) {
handleOOM(fontURI);
}
{code}
{code:java}
try {
OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
EmbeddingMode.AUTO,
EncodingMode.AUTO, useKerning, useAdvanced,
resourceResolver, false, false);
customFont = ttfLoader.getFont();
if (this.eventListener != null) {
customFont.setEventListener(this.eventListener);
}
} catch(OutOfMemoryError e) {
handleOOM(fontURI);
}
{code}
And the handling:
{code:java}
private void handleOOM(URI fontURI) throws IOException {
String sizeMsg = "";
if ("file".equals(fontURI.getScheme())) {
sizeMsg = "The font file size was: " + new
File(fontURI).length() + " bytes";
}
throw new IOException(
"Font is too large. " + sizeMsg);
}
{code}
> Out of memory when loading fonts on Mac - instead it should report font too
> large and continue
> --
>
> Key: FOP-2897
> URL: https://issues.apache.org/jira/browse/FOP-2897
> Project: FOP
> Issue Type: Bug
>Reporter: Dan Caprioara
>Priority: Major
> Fix For: 2.4
>
>
> The FontInfoFinder class collects all the fonts from the system. On Mac there
> are huge font files containing icons. This makes FOP break with
> OutOfMemoryError.
> Probably it should show an warning and throw an IOException instead of OOM
> (IOException does not break the entire processing, just skips the current
> font loading, in this way next fonts can be loaded).
> There are two places in the FontInfoFinder class where the OOM should be
> catched:
> {code:java}
> try {
>TTFFile ttf = new TTFFile(false, false);
>FontFileReader reader = new FontFileReader(in);
>ttcNames = ttf.getTTCnames(reader);
> } catch (OutOfMemoryError oom) {
>handleOOM(fontURI);
> }
> {code}
> {code:java}
> try {
>OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
> EmbeddingMode.AUTO,
> EncodingMode.AUTO, useKerning, useAdvanced,
> resourceResolver, false, false);
>customFont = ttfLoader.getFont();
>if (this.eventListener != null) {
> customFont.setEventListener(this.eventListener);
>}
> } catch(OutOfMemoryError
[jira] [Created] (FOP-2897) Out of memory when loading fonts on Mac - instead it should report font too large and continue
Dan Caprioara created FOP-2897:
--
Summary: Out of memory when loading fonts on Mac - instead it
should report font too large and continue
Key: FOP-2897
URL: https://issues.apache.org/jira/browse/FOP-2897
Project: FOP
Issue Type: Bug
Reporter: Dan Caprioara
Fix For: 2.4
The FontInfoFinder class collects all the fonts from the system. On Mac there
are huge font files containing icons. This makes FOP break with
OutOfMemoryError.
Probably it should show an warning and throw an IOException instead of OOM. In
this way next fonts can be loaded.
There are two places in the FontInfoFinder class where the OOM should be
catched:
{code:java}
try {
TTFFile ttf = new TTFFile(false, false);
FontFileReader reader = new FontFileReader(in);
ttcNames = ttf.getTTCnames(reader);
} catch (OutOfMemoryError oom) {
handleOOM(fontURI);
}
{code}
{code:java}
try {
OFFontLoader ttfLoader = new OFFontLoader(fontURI, fontName, true,
EmbeddingMode.AUTO,
EncodingMode.AUTO, useKerning, useAdvanced,
resourceResolver, false, false);
customFont = ttfLoader.getFont();
if (this.eventListener != null) {
customFont.setEventListener(this.eventListener);
}
} catch(OutOfMemoryError e) {
handleOOM(fontURI);
}
{code}
And the handling:
{code:java}
private void handleOOM(URI fontURI) throws IOException {
String sizeMsg = "";
if ("file".equals(fontURI.getScheme())) {
sizeMsg = "The font file size was: " + new
File(fontURI).length() + " bytes";
}
throw new IOException(
"Font is too large. " + sizeMsg);
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FOP-2892) Font substitutions not working: the DefaultConfiguration.getChild() does not find elements as expected
Dan Caprioara created FOP-2892:
--
Summary: Font substitutions not working: the
DefaultConfiguration.getChild() does not find elements as expected
Key: FOP-2892
URL: https://issues.apache.org/jira/browse/FOP-2892
Project: FOP
Issue Type: Bug
Components: unqualified
Affects Versions: 2.4
Reporter: Dan Caprioara
Starting with FOP 2.4 the avalon framework is not used anymore.
Instead, a {{Configuration}} implementation has been added to the FOP:
{{org.apache.fop.configuration.DefaultConfiguration}}
The problem is that the {{getChild(String)}} method uses
{{getElementsByTagName}} that returns all matching elements in document order,
at any level. The old avalon implementation iterated only through the direct
children. This creates some bugs.
Consider the following configuration:
{code:xml}
{code}
The code from the {{FontManagerConfigurator}}
{code}
DefaultConfiguration fontsCfg = (DefaultConfiguration)cfg.getChild("fonts",
false);
{code}
now gets the first {{fonts}} element, the one containing the autodetect,
instead of getting the direct {{fonts}} element, the one containing the
substitutions.
The patch that solves this is:
{code}
Index: DefaultConfiguration.java
===
--- DefaultConfiguration.java (revision 195722)
+++ DefaultConfiguration.java (working copy)
@@ -108,7 +108,7 @@
@Override
public Configuration getChild(String key) {
-NodeList nl = element.getElementsByTagName(key);
+NodeList nl = element.getChildNodes();
for (int i = 0; i < nl.getLength(); ++i) {
Node n = nl.item(i);
if (n.getNodeName().equals(key)) {
@@ -133,13 +133,17 @@
@Override
public Configuration[] getChildren(String key) {
-NodeList nl = element.getElementsByTagName(key);
-Configuration[] result = new Configuration[nl.getLength()];
+ArrayList result = new ArrayList<>(1);
+
+NodeList nl = element.getChildNodes();
for (int i = 0; i < nl.getLength(); ++i) {
Node n = nl.item(i);
-result[i] = new DefaultConfiguration((Element) n);
+if (n.getNodeName().equals(key)) {
+ result.add(new DefaultConfiguration((Element) n));
+}
}
-return result;
+
+return result.toArray(new Configuration[0]);
}
@Override
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FOP-2809) Excessive wrap when having linefeed-treatment="preserve" and inlines
[
https://issues.apache.org/jira/browse/FOP-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924243#comment-16924243
]
Dan Caprioara commented on FOP-2809:
Possible fix in the LineLayoutManager. Add these methods:
{code:java}
/**
*
* The collectInlineKnuthElements method creates some paragraphs based on
the assumption that
* the child layout managers (that can be one ore more TextLayoutManager or
InlineLayoutManagers)
* are returning a KnuthSequence for each line. By line is understood a
sequence ending in a new line.
* In the Knuth terms, a forced line break is represented by an auxiliary
box with a negative infinite penalty .
*
*
* The assuption proved false when a block like:
*
* inline>
* alpha inline>beta/inline>
* inline>gamma/inline>
* /inline>
*
* was broken into:
*
* inline>
* alpha
* inline>beta/inline>
* inline>gamma/inline>
* /inline>
*
* because the LineLayoutManager had a single child
* InlineLayoutManager, that concatenated all the subtree LM boxes into a
single sequence.
* The {@link LineLayoutManager#collectInlineKnuthElements(LayoutContext)}
is looking for line breaks only at the end of sequences, and
* misses the newlines from the middle of the preformatted text.
*
* The solution is to pre-process each of the sequences and split it if
it is the case.
*
*
*
* @param inlineElements The list of sequences, each representing a line.
Each of the sequence will be analysed and split into multiple ones if a hard
line break is detected.
* @return The list with the sequences.
*/
private List supplementalBreakOfSequences(List
inlineElements) {
List result = new ArrayList<>();
for (KnuthSequence sequence : inlineElements) {
// The 'line' that may need to be split in multiple lines.
if (sequence.isInlineSequence()) {
while(sequence.size() > 0) {
int idx = findNextLineBreakIndex(0, sequence);
if (idx != -1 && idx != sequence.size() - 1) {
result.add(new InlineKnuthSequence(sequence.subList(0, idx + 1)));
sequence = new InlineKnuthSequence(sequence.subList(idx + 1,
sequence.size()));
} else {
result.add(sequence);
break;
}
}
} else {
result.add(sequence);
}
}
return result;
}
private int findNextLineBreakIndex(int start, KnuthSequence sequence) {
int idx = -1;
boolean previousIsBox = false;
for (int i = 0; i < sequence.size() - 1; i++) {
ListElement current = (ListElement) sequence.get(i);
if (previousIsBox && current.isForcedBreak()) {
idx = i;
break;
}
previousIsBox = current.isBox()
&& !((KnuthElement) current).isAuxiliary()
&& ((KnuthElement) current).getWidth() != 0;
}
return idx;
}
{code}
Invoke the first one in the
org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LayoutContext)
method after the inlineElements checking:
{code:java}
InlineLevelLayoutManager curLM;
while ((curLM = (InlineLevelLayoutManager) getChildLM()) != null) {
List inlineElements = curLM.getNextKnuthElements(inlineLC,
effectiveAlignment);
if (inlineElements == null || inlineElements.size() == 0) {
/* curLM.getNextKnuthElements() returned null or an empty list;
* this can happen if there is nothing more to layout,
* so just iterate once more to see if there are other children
*/
continue;
}
// PATCH START
inlineElements = supplementalBreakOfSequences(inlineElements);
// PATCH END
{code}
> Excessive wrap when having linefeed-treatment="preserve" and inlines
>
>
> Key: FOP-2809
> URL: https://issues.apache.org/jira/browse/FOP-2809
> Project: FOP
> Issue Type: Bug
> Components: layout/line
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
>
> The text should be presented on two lines (they are separated by line breaks
> - not by wrapping - is plenty of space in the page):
> {quote}
> line1 line1 line1 line1 LINE1
> line2
> {quote}
> Instead it is on three lines.
> {quote}
> line1 line1 line1 line1
> LINE1
> line2
> {quote}
> The snippet:
> {code:xml}
>
> http://www.w3.org/1999/XSL/Format;
> xmlns:fox="http://xmlgraphics.apache.org/fop/extensions; xml:lang="en-us">
>
> page-height="11in">
>
>
>
>
[jira] [Updated] (FOP-2880) [PATCH] Hyphenated words are not searchable in readers (when accessibilty is turned on)
[
https://issues.apache.org/jira/browse/FOP-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2880:
---
Summary: [PATCH] Hyphenated words are not searchable in readers (when
accessibilty is turned on) (was: [PATCH] Hyphenated words are not searchable
in readers)
> [PATCH] Hyphenated words are not searchable in readers (when accessibilty is
> turned on)
> ---
>
> Key: FOP-2880
> URL: https://issues.apache.org/jira/browse/FOP-2880
> Project: FOP
> Issue Type: Bug
> Components: unqualified
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The hyphenated words are rendered by FOP using the hard hyphen character.
> This contradicts the PDF specification, where in section:
> 14.8.2.2.3 Incidental Artifacts
> clearly states that the SHY soft hyphen U+00AD character should be used.
> The effect is that the hyphenated words are not searchable, and the
> copy/paste feature includes also the hard hyphens, instead of removing them
> and joining the words pieces together.
> Here is a small patch that can be applied on the FOP core project in order to
> fix this - this is more like a proof of concept, the real fix would be to
> change the default hyphenation character * in the FOProppertyMapping and to
> change the font mappings: to remove the replacement of the SHY with the
> HYPHEN, see the org.apache.fop.fonts.CodePointMapping.encStandardEncoding,
> and org.apache.fop.fonts.CodePointMapping.encISOLatin1Encoding
> {code}
>0xad, 0x002D, // hyphen
>0xad, 0x00AD, // hyphen
> {code}
> The patch:
> {code}
> Index: src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> ===
> --- src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> (revision 191037)
> +++ src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
> (working copy)
> @@ -15,7 +15,7 @@
> * limitations under the License.
> */
>
> -/* $Id$ */
> +/* $Id: CommonHyphenation.java 1610839 2014-07-15 20:25:58Z vhennebert $ */
>
> package org.apache.fop.fo.properties;
>
> @@ -184,6 +184,16 @@
> */
> public int getHyphIPD(org.apache.fop.fonts.Font font) {
> char hyphChar = getHyphChar(font);
> +
> +if (hyphChar == '\u00ad') {
> + // Bizarre fix, defining the SHY as default hyphenation character
> in the FOPropertyMapping, leads
> + // to hard hyphens not selectable in the PDF reader.
> + //
> + // Mapping also the hard hyphen makes the character selectable!
> + font.mapChar('\u002d');
> +}
> +
> +
> return font.getCharWidth(hyphChar);
> }
>
> Index: src/main/java/org/apache/fop/fo/FOPropertyMapping.java
> ===
> --- src/main/java/org/apache/fop/fo/FOPropertyMapping.java(revision
> 190759)
> +++ src/main/java/org/apache/fop/fo/FOPropertyMapping.java(working copy)
> @@ -1106,7 +1106,10 @@
> // hyphenation-character
> m = new CharacterProperty.Maker(PR_HYPHENATION_CHARACTER);
> m.setInherited(true);
> -m.setDefault("-");
> +//
> +// m.setDefault("-");
> +m.setDefault("\u00ad");
> +
> addPropertyMaker("hyphenation-character", m);
>
> // hyphenation-push-character-count
> Index: src/main/java/org/apache/fop/render/pdf/PDFPainter.java
> ===
> --- src/main/java/org/apache/fop/render/pdf/PDFPainter.java (revision
> 190759)
> +++ src/main/java/org/apache/fop/render/pdf/PDFPainter.java (working copy)
> @@ -420,7 +420,8 @@
> PDFStructElem structElem = (PDFStructElem)
> getContext().getStructureTreeElement();
> languageAvailabilityChecker.checkLanguageAvailability(text);
> MarkedContentInfo mci =
> logicalStructureHandler.addTextContentItem(structElem);
> -String actualText = getContext().isHyphenated() ?
> text.substring(0, text.length() - 1) : null;
> +//String actualText = getContext().isHyphenated() ?
> text.substring(0, text.length() - 1) : null;
> +String actualText = null;
> generator.endTextObject();
> generator.updateColor(state.getTextColor(), true, null);
> generator.beginTextObject(mci.tag, mci.mcid, actualText);
> @@ -490,6 +491,15 @@
> float glyphAdjust = 0;
> if (font.hasCodePoint(orgChar)) {
> ch = font.mapCodePoint(orgChar);
> + if
[jira] [Updated] (FOP-2880) [PATCH] Hyphenated words are not searchable in readers
[
https://issues.apache.org/jira/browse/FOP-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2880:
---
Description:
The hyphenated words are rendered by FOP using the hard hyphen character. This
contradicts the PDF specification, where in section:
14.8.2.2.3 Incidental Artifacts
clearly states that the SHY soft hyphen U+00AD character should be used.
The effect is that the hyphenated words are not searchable, and the copy/paste
feature includes also the hard hyphens, instead of removing them and joining
the words pieces together.
Here is a small patch that can be applied on the FOP core project in order to
fix this - this is more like a proof of concept, the real fix would be to
change the default hyphenation character * in the FOProppertyMapping and to
change the font mappings: to remove the replacement of the SHY with the
HYPHEN, see the org.apache.fop.fonts.CodePointMapping.encStandardEncoding, and
org.apache.fop.fonts.CodePointMapping.encISOLatin1Encoding
{code}
0xad, 0x002D, // hyphen
0xad, 0x00AD, // hyphen
{code}
The patch:
{code}
Index: src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
===
--- src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
(revision 191037)
+++ src/main/java/org/apache/fop/fo/properties/CommonHyphenation.java
(working copy)
@@ -15,7 +15,7 @@
* limitations under the License.
*/
-/* $Id$ */
+/* $Id: CommonHyphenation.java 1610839 2014-07-15 20:25:58Z vhennebert $ */
package org.apache.fop.fo.properties;
@@ -184,6 +184,16 @@
*/
public int getHyphIPD(org.apache.fop.fonts.Font font) {
char hyphChar = getHyphChar(font);
+
+if (hyphChar == '\u00ad') {
+ // Bizarre fix, defining the SHY as default hyphenation character in
the FOPropertyMapping, leads
+ // to hard hyphens not selectable in the PDF reader.
+ //
+ // Mapping also the hard hyphen makes the character selectable!
+ font.mapChar('\u002d');
+}
+
+
return font.getCharWidth(hyphChar);
}
Index: src/main/java/org/apache/fop/fo/FOPropertyMapping.java
===
--- src/main/java/org/apache/fop/fo/FOPropertyMapping.java (revision
190759)
+++ src/main/java/org/apache/fop/fo/FOPropertyMapping.java (working copy)
@@ -1106,7 +1106,10 @@
// hyphenation-character
m = new CharacterProperty.Maker(PR_HYPHENATION_CHARACTER);
m.setInherited(true);
-m.setDefault("-");
+//
+// m.setDefault("-");
+m.setDefault("\u00ad");
+
addPropertyMaker("hyphenation-character", m);
// hyphenation-push-character-count
Index: src/main/java/org/apache/fop/render/pdf/PDFPainter.java
===
--- src/main/java/org/apache/fop/render/pdf/PDFPainter.java (revision
190759)
+++ src/main/java/org/apache/fop/render/pdf/PDFPainter.java (working copy)
@@ -420,7 +420,8 @@
PDFStructElem structElem = (PDFStructElem)
getContext().getStructureTreeElement();
languageAvailabilityChecker.checkLanguageAvailability(text);
MarkedContentInfo mci =
logicalStructureHandler.addTextContentItem(structElem);
-String actualText = getContext().isHyphenated() ?
text.substring(0, text.length() - 1) : null;
+//String actualText = getContext().isHyphenated() ?
text.substring(0, text.length() - 1) : null;
+String actualText = null;
generator.endTextObject();
generator.updateColor(state.getTextColor(), true, null);
generator.beginTextObject(mci.tag, mci.mcid, actualText);
@@ -490,6 +491,15 @@
float glyphAdjust = 0;
if (font.hasCodePoint(orgChar)) {
ch = font.mapCodePoint(orgChar);
+ if (orgChar ==
'\u00ad' && ch == '\u002d'){
+ // Map it
back to the SHY, the hard hyphen is not correct, causes the hyphenated words
not being searchable.
+ // See the
PDF Spec: 14.8.2.2.3 Incidental Artifacts / Hyphenation paragraph.
+
+ // The ansi
encoding CodePointMapping has the hyphenation char with two entries,
+ // the first
is selected, the hard hyphen. Reverting...
+ ch = orgChar;
+ }
+
[jira] [Created] (FOP-2880) [PATCH] Hyphenated words are not searchable in readers
Dan Caprioara created FOP-2880:
--
Summary: [PATCH] Hyphenated words are not searchable in readers
Key: FOP-2880
URL: https://issues.apache.org/jira/browse/FOP-2880
Project: FOP
Issue Type: Bug
Components: unqualified
Affects Versions: 2.3
Reporter: Dan Caprioara
The hyphenated words are rendered by FOP using the hard hyphen character. This
contradicts the PDF specification, where in section:
14.8.2.2.3 Incidental Artifacts
clearly states that the SHY soft hyphen U+00AD character should be used.
The effect is that the hyphenated words are not searchable, and the copy/paste
feature includes also the hard hyphens, instead of removing them and joining
the words pieces together.
Here is a small patch that can be applied on the FOP core project in order to
fix this:
{code}
Index: src/main/java/org/apache/fop/fo/FOPropertyMapping.java
===
--- src/main/java/org/apache/fop/fo/FOPropertyMapping.java (revision
190759)
+++ src/main/java/org/apache/fop/fo/FOPropertyMapping.java (working copy)
@@ -1106,7 +1106,10 @@
// hyphenation-character
m = new CharacterProperty.Maker(PR_HYPHENATION_CHARACTER);
m.setInherited(true);
-m.setDefault("-");
+
+// m.setDefault("-");
+m.setDefault("\u00ad");
+
addPropertyMaker("hyphenation-character", m);
// hyphenation-push-character-count
Index: src/main/java/org/apache/fop/render/pdf/PDFPainter.java
===
--- src/main/java/org/apache/fop/render/pdf/PDFPainter.java (revision
190759)
+++ src/main/java/org/apache/fop/render/pdf/PDFPainter.java (working copy)
@@ -420,7 +420,8 @@
PDFStructElem structElem = (PDFStructElem)
getContext().getStructureTreeElement();
languageAvailabilityChecker.checkLanguageAvailability(text);
MarkedContentInfo mci =
logicalStructureHandler.addTextContentItem(structElem);
-String actualText = getContext().isHyphenated() ?
text.substring(0, text.length() - 1) : null;
+//String actualText = getContext().isHyphenated() ?
text.substring(0, text.length() - 1) : null;
+String actualText = null;
generator.endTextObject();
generator.updateColor(state.getTextColor(), true, null);
generator.beginTextObject(mci.tag, mci.mcid, actualText);
@@ -490,6 +491,14 @@
float glyphAdjust = 0;
if (font.hasCodePoint(orgChar)) {
ch = font.mapCodePoint(orgChar);
+ if (orgChar ==
'\u00ad'){
+ // Map it
back to the SHY, the hard hyphen is not correct, causes the hyphenated words
not being searchable.
+ // See the
PDF Spec: 14.8.2.2.3 Incidental Artifacts / Hyphenation paragraph.
+
+ // The ansi
encoding CodePointMapping has the hyphenation char with two entries,
+ // the first
is selected, the hard hyphen. Reverting...
+ ch = orgChar;
+ }
ch = selectAndMapSingleByteFont(tf, fontName, fontSize,
textutil, ch);
if ((wordSpacing != 0) &&
CharUtilities.isAdjustableSpace(orgChar)) {
glyphAdjust += wordSpacing;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (FOP-2872) NullPointerException when an SVG root element specifies the size in 'em' (and a fix for this)
Dan Caprioara created FOP-2872:
--
Summary: NullPointerException when an SVG root element specifies
the size in 'em' (and a fix for this)
Key: FOP-2872
URL: https://issues.apache.org/jira/browse/FOP-2872
Project: FOP
Issue Type: Bug
Components: foreign/svg
Affects Versions: 2.3
Reporter: Dan Caprioara
This is the sample FO file, the SVG has its height specified in 'em' dimension:
{code:xml}
http://www.w3.org/1999/XSL/Format;
xmlns:fox="http://xmlgraphics.apache.org/fop/extensions;>
Testing SVG images,
there should be no NPE
This is a SVG with its size
in em: http://www.w3.org/2000/svg;>
{code}
The exception is:
{code:java}
ava.lang.NullPointerException
at
org.apache.batik.bridge.UnitProcessor$DefaultContext.getFontSize(UnitProcessor.java:384)
at
org.apache.batik.parser.UnitProcessor.emsToPixels(UnitProcessor.java:286)
at
org.apache.batik.parser.UnitProcessor.svgToUserSpace(UnitProcessor.java:171)
at
org.apache.batik.parser.UnitProcessor.svgToUserSpace(UnitProcessor.java:140)
at
org.apache.batik.bridge.UnitProcessor.svgToUserSpace(UnitProcessor.java:310)
at
org.apache.batik.bridge.UnitProcessor.svgLengthToUserSpace(UnitProcessor.java:286)
at
org.apache.batik.bridge.UnitProcessor.svgVerticalLengthToUserSpace(UnitProcessor.java:217)
at
org.apache.fop.image.loader.batik.PreloaderSVG$Loader.createImageInfo(PreloaderSVG.java:191)
at
org.apache.fop.image.loader.batik.PreloaderSVG$Loader.getImage(PreloaderSVG.java:131)
at
org.apache.fop.image.loader.batik.PreloaderSVG$Loader.access$200(PreloaderSVG.java:108)
at
org.apache.fop.image.loader.batik.PreloaderSVG.preloadImage(PreloaderSVG.java:76)
at
org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:176)
{code}
The cause is the document misses a CSSEngine, the SVG preloader does not
provide one.
The solution is to have the preloader initialize the document using the bridge
context:
{code:java}
Index: src/main/java/org/apache/batik/bridge/BridgeContext.java
===
--- src/main/java/org/apache/batik/bridge/BridgeContext.java(revision
189449)
+++ src/main/java/org/apache/batik/bridge/BridgeContext.java(working copy)
@@ -372,7 +372,7 @@
/**
* Initializes the given document.
*/
-protected void initializeDocument(Document document) {
+public void initializeDocument(Document document) {
SVGOMDocument doc = (SVGOMDocument)document;
CSSEngine eng = doc.getCSSEngine();
if (eng == null) {
Index: src/main/java/org/apache/fop/image/loader/batik/PreloaderSVG.java
===
--- src/main/java/org/apache/fop/image/loader/batik/PreloaderSVG.java
(revision 189449)
+++ src/main/java/org/apache/fop/image/loader/batik/PreloaderSVG.java
(working copy)
@@ -172,6 +172,7 @@
};
BridgeContext ctx = new BridgeContext(userAg);
+ctx.initializeDocument(doc);
UnitProcessor.Context uctx = UnitProcessor.createContext(ctx, e);
String s;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FOP-2349) Inline elements with letter-spacing and custom font aren't correctly sized
[ https://issues.apache.org/jira/browse/FOP-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844566#comment-16844566 ] Dan Caprioara commented on FOP-2349: I get the same problem when using Arial with negative letter spacing. > Inline elements with letter-spacing and custom font aren't correctly sized > -- > > Key: FOP-2349 > URL: https://issues.apache.org/jira/browse/FOP-2349 > Project: FOP > Issue Type: Bug > Components: layout/unqualified >Reporter: Matthias Reischenbacher >Priority: Major > Attachments: FOP-2349.fo, inline-letter-spacing.pdf, > inline-letter-spacing.xml > > > If letter-spacing is applied to an inline element, that uses one of the > base-14 fonts, the width of the inline element is automatically expanded with > the letter-spacing. > However if a custom font is used (e.g. Arial) the inline width isn't expanded > anymore, which prevents from using background-color or borders for the inline > element. > See attached PDF which illustrates the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FOP-2776) NoSuchElementException for list changing ipd
[
https://issues.apache.org/jira/browse/FOP-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756056#comment-16756056
]
Dan Caprioara commented on FOP-2776:
The fix introduced a new bug. If you have two list, one nested into another,
the nested list jumps to the next page instead of spreading on two pages. It is
like the parent list item has a keep-together property set on it. Removing the
code added by this fix solves the problem.
Here is a file to test with.
The item with the number 15 from the parent list item moves on the second page,
together with the nested list. In FOP 2.2 the page breaking was done between
the items of the nested list.
{code}
http://www.w3.org/1999/XSL/Format;>
Sample FO document
1.
outer
2.
outer
3.
outer
4.
outer
5.
outer
6.
outer
7.
outer
8.
outer
9.
outer
10.
outer
11.
outer
12.
outer
13.
outer
14.
outer
15.
Now
a nested long list:
1.
inner
2.
inner
3.
inner
4.
[jira] [Commented] (FOP-2820) [PATCH] Top/Bottom borders and padding of block containers are repeated after the page break
[
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668523#comment-16668523
]
Dan Caprioara commented on FOP-2820:
I tested with both AntennaHouse and XEP, and they do not repeat the top, bottom
borders at the page breaks on the block containers as FOP does. In the
specification and I do not see any difference between the fo:block and the
fo:block-container regarding to borders/padding
(https://www.w3.org/TR/xsl11/#d0e9451). So in my opinion this is a FOP bug.
> [PATCH] Top/Bottom borders and padding of block containers are repeated after
> the page break
>
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: block-container_borders-padding-and-page-breaks.xml,
> fo-block-container.png, fo-block.png, fop.patch
>
>
> There is a big difference between a block and a block-container regarding the
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
> !fo-block.png!
> But instead is like this ( this is a {{fo:block-container -}} ignore the
> text, chck the borders):
> !fo-block-container.png!
> If you have a longer text in the block container and it spans on several
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FOP-2820) Top/Bottom borders and padding of block containers are repeated after the page break
[
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16643008#comment-16643008
]
Dan Caprioara commented on FOP-2820:
I have attached a patch and the test file for the layout engine.
The top padding and border are applied only at the beginning of the block
container, on the first page.
The bottom padding and border are applied only at the end of the block
container, on the last page.
> Top/Bottom borders and padding of block containers are repeated after the
> page break
>
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: block-container_borders-padding-and-page-breaks.xml,
> fo-block-container.png, fo-block.png, fop.patch
>
>
> There is a big difference between a block and a block-container regarding the
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
> !fo-block.png!
> But instead is like this ( this is a {{fo:block-container -}} ignore the
> text, chck the borders):
> !fo-block-container.png!
> If you have a longer text in the block container and it spans on several
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FOP-2820) Top/Bottom borders and padding of block containers are repeated after the page break
[
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2820:
---
Attachment: fop.patch
> Top/Bottom borders and padding of block containers are repeated after the
> page break
>
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: block-container_borders-padding-and-page-breaks.xml,
> fo-block-container.png, fo-block.png, fop.patch
>
>
> There is a big difference between a block and a block-container regarding the
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
> !fo-block.png!
> But instead is like this ( this is a {{fo:block-container -}} ignore the
> text, chck the borders):
> !fo-block-container.png!
> If you have a longer text in the block container and it spans on several
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FOP-2820) Top/Bottom borders and padding of block containers are repeated after the page break
[
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2820:
---
Attachment: block-container_borders-padding-and-page-breaks.xml
> Top/Bottom borders and padding of block containers are repeated after the
> page break
>
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: block-container_borders-padding-and-page-breaks.xml,
> fo-block-container.png, fo-block.png
>
>
> There is a big difference between a block and a block-container regarding the
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
> !fo-block.png!
> But instead is like this ( this is a {{fo:block-container -}} ignore the
> text, chck the borders):
> !fo-block-container.png!
> If you have a longer text in the block container and it spans on several
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FOP-2820) Top/Bottom borders and padding of block containers are repeated after the page break
[
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2820:
---
Description:
There is a big difference between a block and a block-container regarding the
borders and padding when the page breaks.
The borders should be like this (this is a plain {{fo:block}}):
!fo-block.png!
But instead is like this ( this is a {{fo:block-container -}} ignore the text,
chck the borders):
!fo-block-container.png!
If you have a longer text in the block container and it spans on several pages
then it starts to bleed out of the page.
I found a fix for that, I will post it below.
was:
There is a big difference between a block and a block-container regarding the
borders and padding when the page breaks.
The borders should be like this (this is a plain {{fo:block}}):
!image-2018-10-08-12-20-35-287.png!
But instead is like this ( this is a {{fo:block-container}}, ignore the text,
see the borders):
!image-2018-10-08-12-17-46-171.png!
If you have a longer text in the block container and it spans on several pages
then it starts to bleed out of the page.
I found a fix for that, I will post it below.
> Top/Bottom borders and padding of block containers are repeated after the
> page break
>
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: fo-block-container.png, fo-block.png
>
>
> There is a big difference between a block and a block-container regarding the
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
> !fo-block.png!
> But instead is like this ( this is a {{fo:block-container -}} ignore the
> text, chck the borders):
> !fo-block-container.png!
> If you have a longer text in the block container and it spans on several
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FOP-2820) Top/Bottom borders and padding of block containers are repeated after the page break
[
https://issues.apache.org/jira/browse/FOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2820:
---
Attachment: fo-block.png
fo-block-container.png
> Top/Bottom borders and padding of block containers are repeated after the
> page break
>
>
> Key: FOP-2820
> URL: https://issues.apache.org/jira/browse/FOP-2820
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: fo-block-container.png, fo-block.png
>
>
> There is a big difference between a block and a block-container regarding the
> borders and padding when the page breaks.
> The borders should be like this (this is a plain {{fo:block}}):
> !image-2018-10-08-12-20-35-287.png!
> But instead is like this ( this is a {{fo:block-container}}, ignore the text,
> see the borders):
> !image-2018-10-08-12-17-46-171.png!
> If you have a longer text in the block container and it spans on several
> pages then it starts to bleed out of the page.
> I found a fix for that, I will post it below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FOP-2820) Top/Bottom borders and padding of block containers are repeated after the page break
Dan Caprioara created FOP-2820:
--
Summary: Top/Bottom borders and padding of block containers are
repeated after the page break
Key: FOP-2820
URL: https://issues.apache.org/jira/browse/FOP-2820
Project: FOP
Issue Type: Bug
Components: layout/block
Affects Versions: 2.3
Reporter: Dan Caprioara
There is a big difference between a block and a block-container regarding the
borders and padding when the page breaks.
The borders should be like this (this is a plain {{fo:block}}):
!image-2018-10-08-12-20-35-287.png!
But instead is like this ( this is a {{fo:block-container}}, ignore the text,
see the borders):
!image-2018-10-08-12-17-46-171.png!
If you have a longer text in the block container and it spans on several pages
then it starts to bleed out of the page.
I found a fix for that, I will post it below.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FOP-2704) Google fonts Roboto font (updated 2017) UnsupportedOperationException: coverage set class table not yet supported
[
https://issues.apache.org/jira/browse/FOP-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16617442#comment-16617442
]
Dan Caprioara commented on FOP-2704:
This is a workaround disables too many font features. What would mean to
support the "coverage set class table" ?
> Google fonts Roboto font (updated 2017) UnsupportedOperationException:
> coverage set class table not yet supported
> -
>
> Key: FOP-2704
> URL: https://issues.apache.org/jira/browse/FOP-2704
> Project: FOP
> Issue Type: Bug
> Components: font/opentype
>Affects Versions: 2.1, 2.2
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: Roboto-Regular.ttf, Roboto-Thin.ttf
>
>
> Steps:
> # Download the Roboto TTF font from Google Fonts.
> # Create a configuration file with a triplet pointing to the "roboto-regular"
> or "roboto-thin" TTF file.
> You get:
> {code}
> java.lang.UnsupportedOperationException: coverage set class table not yet
> supported
> at
> org.apache.fop.complexscripts.fonts.GlyphClassTable$CoverageSetClassTable.(GlyphClassTable.java:262)
> at
> org.apache.fop.complexscripts.fonts.GlyphClassTable.createClassTable(GlyphClassTable.java:88)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEFMarkGlyphsTableFormat1(OTFAdvancedTypographicTableReader_Original.java:3344)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readGDEFMarkGlyphsTableFormat1(OTFAdvancedTypographicTableReader.java:69)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEFMarkGlyphsTable(OTFAdvancedTypographicTableReader_Original.java:3357)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEF(OTFAdvancedTypographicTableReader_Original.java:3427)
> at
> org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readAll(OTFAdvancedTypographicTableReader_Original.java:80)
> at
> org.apache.fop.fonts.truetype.OpenFont.handleCharacterSpacing(OpenFont.java:786)
> at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:755)
> at
> org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
> at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
> {code}
> There are two changes that should be done to the
> {{OTFAdvancedTypographicTableReader}}.
> # The method {{readGDEFMarkGlyphsTableFormat1}} should catch this exception
> # The method {{constructLookupsLanguage}} should check if the {{languages}}
> parameter is null.
> After these changes, the PDF is produced and it looks good. I am not sure
> what are the side effects on the font that is embedded into the PDF..
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FOP-2731) Position:fixed uses a bad reference area
[
https://issues.apache.org/jira/browse/FOP-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2731:
---
Attachment: fop.patch
> Position:fixed uses a bad reference area
>
>
> Key: FOP-2731
> URL: https://issues.apache.org/jira/browse/FOP-2731
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.2
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: fop.patch, position-fixed-bad-reference-area.png,
> position.fo
>
>
> When trying to place some elements to the corners of the page, it seems that
> FOP uses some wrong dimensions. Take a look at the attached screenshot,
> showing the difference between FOP and AntennaHouse.
> {code}
>
> xml:lang="dflt"
> xmlns:css="http://www.w3.org/1998/CSS;
> xmlns:fo="http://www.w3.org/1999/XSL/Format;>
>
>
> master-name="css2fo-default">
>
> blank-or-not-blank="any"
> master-reference="spm-css2fo-default"
> odd-or-even="any"
> page-position="any"/>
>
>
> master-name="spm-css2fo-default"
> page-height="8.27in"
> page-width="5.83in">
> border-bottom-color="orange"
> border-bottom-style="solid"
> border-bottom-width="2pt"
> border-left-color="orange"
> border-left-style="solid"
> border-left-width="2pt"
> border-right-color="orange"
> border-right-style="solid"
> border-right-width="2pt"
> border-top-color="orange"
> border-top-style="solid"
> border-top-width="2pt"
> margin-bottom="1in"
> margin-left="1in"
> margin-right="1in"
> margin-top="1in"/>
> extent="1in"
> region-name="sc-before"/>
> extent="1in"
> region-name="sc-after"/>
> extent="1in"
> region-name="sc-start"/>
> extent="1in"
> region-name="sc-end"/>
>
>
>
> xmlns:x="adobe:ns:meta/">
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>
> xmlns:xmp="http://ns.adobe.com/xap/1.0/;>oXygen PDF
> Chemistry
>
>
>
>
> force-page-count="no-force"
> id="last-page-sequence"
> line-height-shift-adjustment="disregard-shifts"
> master-reference="css2fo-default">
> flow-name="xsl-region-body">
> font-family="serif"
> font-size="12pt">
> font-size="larger"
> font-style="oblique">An element with position: fixed is
> positioned relative to its
> page.
> 1. Normal div.
> border-bottom-color="red"
> border-bottom-style="solid"
> border-bottom-width="3pt"
> border-left-color="red"
> border-left-style="solid"
> border-left-width="3pt"
> border-right-color="red"
> border-right-style="solid"
> border-right-width="3pt"
> border-top-color="red"
> border-top-style="solid"
> border-top-width="3pt"
> height="100pt"
> left="10pt"
> position="fixed"
> top="10pt"
> width="100pt">
> end-indent="0"
> start-indent="0">Fixed top left.
>
> border-bottom-color="red"
> border-bottom-style="solid"
> border-bottom-width="3pt"
> border-left-color="red"
> border-left-style="solid"
> border-left-width="3pt"
> border-right-color="red"
> border-right-style="solid"
> border-right-width="3pt"
> border-top-color="red"
> border-top-style="solid"
> border-top-width="3pt"
> height="100pt"
> position="fixed"
> right="10pt"
>
[jira] [Commented] (FOP-2731) Position:fixed uses a bad reference area
[
https://issues.apache.org/jira/browse/FOP-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16617441#comment-16617441
]
Dan Caprioara commented on FOP-2731:
Added the XSL-FO file and the patch. I am not sure how/were to create a
testcase.
> Position:fixed uses a bad reference area
>
>
> Key: FOP-2731
> URL: https://issues.apache.org/jira/browse/FOP-2731
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.2
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: fop.patch, position-fixed-bad-reference-area.png,
> position.fo
>
>
> When trying to place some elements to the corners of the page, it seems that
> FOP uses some wrong dimensions. Take a look at the attached screenshot,
> showing the difference between FOP and AntennaHouse.
> {code}
>
> xml:lang="dflt"
> xmlns:css="http://www.w3.org/1998/CSS;
> xmlns:fo="http://www.w3.org/1999/XSL/Format;>
>
>
> master-name="css2fo-default">
>
> blank-or-not-blank="any"
> master-reference="spm-css2fo-default"
> odd-or-even="any"
> page-position="any"/>
>
>
> master-name="spm-css2fo-default"
> page-height="8.27in"
> page-width="5.83in">
> border-bottom-color="orange"
> border-bottom-style="solid"
> border-bottom-width="2pt"
> border-left-color="orange"
> border-left-style="solid"
> border-left-width="2pt"
> border-right-color="orange"
> border-right-style="solid"
> border-right-width="2pt"
> border-top-color="orange"
> border-top-style="solid"
> border-top-width="2pt"
> margin-bottom="1in"
> margin-left="1in"
> margin-right="1in"
> margin-top="1in"/>
> extent="1in"
> region-name="sc-before"/>
> extent="1in"
> region-name="sc-after"/>
> extent="1in"
> region-name="sc-start"/>
> extent="1in"
> region-name="sc-end"/>
>
>
>
> xmlns:x="adobe:ns:meta/">
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>
> xmlns:xmp="http://ns.adobe.com/xap/1.0/;>oXygen PDF
> Chemistry
>
>
>
>
> force-page-count="no-force"
> id="last-page-sequence"
> line-height-shift-adjustment="disregard-shifts"
> master-reference="css2fo-default">
> flow-name="xsl-region-body">
> font-family="serif"
> font-size="12pt">
> font-size="larger"
> font-style="oblique">An element with position: fixed is
> positioned relative to its
> page.
> 1. Normal div.
> border-bottom-color="red"
> border-bottom-style="solid"
> border-bottom-width="3pt"
> border-left-color="red"
> border-left-style="solid"
> border-left-width="3pt"
> border-right-color="red"
> border-right-style="solid"
> border-right-width="3pt"
> border-top-color="red"
> border-top-style="solid"
> border-top-width="3pt"
> height="100pt"
> left="10pt"
> position="fixed"
> top="10pt"
> width="100pt">
> end-indent="0"
> start-indent="0">Fixed top left.
>
> border-bottom-color="red"
> border-bottom-style="solid"
> border-bottom-width="3pt"
> border-left-color="red"
> border-left-style="solid"
> border-left-width="3pt"
> border-right-color="red"
> border-right-style="solid"
> border-right-width="3pt"
> border-top-color="red"
> border-top-style="solid"
> border-top-width="3pt"
>
[jira] [Updated] (FOP-2731) Position:fixed uses a bad reference area
[
https://issues.apache.org/jira/browse/FOP-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2731:
---
Attachment: position.fo
> Position:fixed uses a bad reference area
>
>
> Key: FOP-2731
> URL: https://issues.apache.org/jira/browse/FOP-2731
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.2
>Reporter: Dan Caprioara
>Priority: Major
> Attachments: position-fixed-bad-reference-area.png, position.fo
>
>
> When trying to place some elements to the corners of the page, it seems that
> FOP uses some wrong dimensions. Take a look at the attached screenshot,
> showing the difference between FOP and AntennaHouse.
> {code}
>
> xml:lang="dflt"
> xmlns:css="http://www.w3.org/1998/CSS;
> xmlns:fo="http://www.w3.org/1999/XSL/Format;>
>
>
> master-name="css2fo-default">
>
> blank-or-not-blank="any"
> master-reference="spm-css2fo-default"
> odd-or-even="any"
> page-position="any"/>
>
>
> master-name="spm-css2fo-default"
> page-height="8.27in"
> page-width="5.83in">
> border-bottom-color="orange"
> border-bottom-style="solid"
> border-bottom-width="2pt"
> border-left-color="orange"
> border-left-style="solid"
> border-left-width="2pt"
> border-right-color="orange"
> border-right-style="solid"
> border-right-width="2pt"
> border-top-color="orange"
> border-top-style="solid"
> border-top-width="2pt"
> margin-bottom="1in"
> margin-left="1in"
> margin-right="1in"
> margin-top="1in"/>
> extent="1in"
> region-name="sc-before"/>
> extent="1in"
> region-name="sc-after"/>
> extent="1in"
> region-name="sc-start"/>
> extent="1in"
> region-name="sc-end"/>
>
>
>
> xmlns:x="adobe:ns:meta/">
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>
> xmlns:xmp="http://ns.adobe.com/xap/1.0/;>oXygen PDF
> Chemistry
>
>
>
>
> force-page-count="no-force"
> id="last-page-sequence"
> line-height-shift-adjustment="disregard-shifts"
> master-reference="css2fo-default">
> flow-name="xsl-region-body">
> font-family="serif"
> font-size="12pt">
> font-size="larger"
> font-style="oblique">An element with position: fixed is
> positioned relative to its
> page.
> 1. Normal div.
> border-bottom-color="red"
> border-bottom-style="solid"
> border-bottom-width="3pt"
> border-left-color="red"
> border-left-style="solid"
> border-left-width="3pt"
> border-right-color="red"
> border-right-style="solid"
> border-right-width="3pt"
> border-top-color="red"
> border-top-style="solid"
> border-top-width="3pt"
> height="100pt"
> left="10pt"
> position="fixed"
> top="10pt"
> width="100pt">
> end-indent="0"
> start-indent="0">Fixed top left.
>
> border-bottom-color="red"
> border-bottom-style="solid"
> border-bottom-width="3pt"
> border-left-color="red"
> border-left-style="solid"
> border-left-width="3pt"
> border-right-color="red"
> border-right-style="solid"
> border-right-width="3pt"
> border-top-color="red"
> border-top-style="solid"
> border-top-width="3pt"
> height="100pt"
> position="fixed"
> right="10pt"
>
[jira] [Created] (FOP-2816) The property keep-together.within-page='always' implies keep-together.within-column='always' (there should be a difference)
Dan Caprioara created FOP-2816:
--
Summary: The property keep-together.within-page='always' implies
keep-together.within-column='always' (there should be a difference)
Key: FOP-2816
URL: https://issues.apache.org/jira/browse/FOP-2816
Project: FOP
Issue Type: Bug
Components: layout/page
Affects Versions: 2.3
Reporter: Dan Caprioara
This is an example: A document having two columns and as series of small
sections, called steps. Each of the "step" block has the attributes:
{code:java}
keep-together.within-column="auto"
keep-together.within-page="always"
{code}
The "step" at the end of the first column should break on the two columns, as
it has {{keep-together.within-column="auto"}}. Instead it moves completely to
the second column.
In fact it behaves as the column breaks and page breaks are considered by FOP
to be the same thing.
{code:xml}
http://www.oxygenxml.com/chemistry/extensions/fop;
xmlns:css="http://www.w3.org/1998/CSS;
xmlns:fo="http://www.w3.org/1999/XSL/Format;
xmlns:fox="http://xmlgraphics.apache.org/fop/extensions;>
The step should not break on two pages, but
should break on two
columns .
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
This is a step with some text content that should
wrap somehow on
multiple lines.
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FOP-2810) Incomplete implementation of the simulate-style flag
Dan Caprioara created FOP-2810:
--
Summary: Incomplete implementation of the simulate-style flag
Key: FOP-2810
URL: https://issues.apache.org/jira/browse/FOP-2810
Project: FOP
Issue Type: Bug
Components: font/unqualified
Affects Versions: 2.3
Reporter: Dan Caprioara
The CustomFont.getSimulateStyle() is used only in:
{code:java}
org.apache.fop.render.pdf.PDFPainter.drawTextWithDX(int, int, String,
FontTriplet, int, int, int[])
{code}
But not in:
{code:java}
org.apache.fop.render.pdf.PDFPainter.drawTextWithDP(int, int, String,
FontTriplet, int, int, int[][])
{code}
As a result some of the font styling is not applied.
Modifying the above method with the following patch seem to fix the problem:
{code:java}
...
boolean simulateStyle = tf instanceof CustomFont && ((CustomFont)
tf).getSimulateStyle();
// PATCH START
// Taken from #drawTextWithDX method
double shear = 0;
if (simulateStyle) {
//Adding this breaks the PDF: generator.add("q\n")
if (triplet.getWeight() == 700) {
generator.add("2 Tr 0.31543 w\n");
}
if (triplet.getStyle().equals("italic")) {
shear = 0.333;
}
}
// PATCH END
tu.writeTextMatrix(new AffineTransform(1, 0, shear, -1, x / 1000f,
y / 1000f));
tu.updateTf(fk, fsPoints, true);
generator.updateCharacterSpacing(letterSpacing / 1000f);
...
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FOP-2809) Excessive wrap when having linefeed-treatment="preserve" and inlines
[
https://issues.apache.org/jira/browse/FOP-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Caprioara updated FOP-2809:
---
Description:
The text should be presented on two lines (they are separated by line breaks -
not by wrapping - is plenty of space in the page):
{quote}
line1 line1 line1 line1 LINE1
line2
{quote}
Instead it is on three lines.
{quote}
line1 line1 line1 line1
LINE1
line2
{quote}
The snippet:
{code:xml}
http://www.w3.org/1999/XSL/Format;
xmlns:fox="http://xmlgraphics.apache.org/fop/extensions; xml:lang="en-us">
line1 line1 line1 line1
LINE1
line2
{code}
If you add more words to the example, you will see that it always add a break
before the second-to-last word.
If you remove the inline: {{line2}} and leave just the
{{line2}} text, this corrects the problem. The same if you remove the tags of
any inline.
was:
The text should be presented on two lines:
{quote}
line1 line1 line1 line1 LINE1
line2
{quote}
But is like this, on three lines.
{quote}
line1 line1 line1 line1
LINE1
line2
{quote}
The snippet:
{code:xml}
http://www.w3.org/1999/XSL/Format;
xmlns:fox="http://xmlgraphics.apache.org/fop/extensions; xml:lang="en-us">
line1 line1 line1 line1
LINE1
line2
{code}
If you add words to the example, you will see that it always add a break before
the second-to-last word.
If you remove the inline: {{line2}} and leave just the
{{line2}} text, this corrects the problem. The same if you remove the tags of
any inline.
> Excessive wrap when having linefeed-treatment="preserve" and inlines
>
>
> Key: FOP-2809
> URL: https://issues.apache.org/jira/browse/FOP-2809
> Project: FOP
> Issue Type: Bug
> Components: layout/line
>Affects Versions: 2.3
>Reporter: Dan Caprioara
>Priority: Major
>
> The text should be presented on two lines (they are separated by line breaks
> - not by wrapping - is plenty of space in the page):
> {quote}
> line1 line1 line1 line1 LINE1
> line2
> {quote}
> Instead it is on three lines.
> {quote}
> line1 line1 line1 line1
> LINE1
> line2
> {quote}
> The snippet:
> {code:xml}
>
> http://www.w3.org/1999/XSL/Format;
> xmlns:fox="http://xmlgraphics.apache.org/fop/extensions; xml:lang="en-us">
>
> page-height="11in">
>
>
>
>force-page-count="no-force"
> id="last-page-sequence" line-height-shift-adjustment="disregard-shifts">
>
>
>wrap-option="wrap">line1 line1 line1 line1
> LINE1
> line2
>
>
>
>
> {code}
> If you add more words to the example, you will see that it always add a break
> before the second-to-last word.
> If you remove the inline: {{line2}} and leave just the
> {{line2}} text, this corrects the problem. The same if you remove the tags
> of any inline.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FOP-2809) Excessive wrap when having linefeed-treatment="preserve" and inlines
Dan Caprioara created FOP-2809:
--
Summary: Excessive wrap when having linefeed-treatment="preserve"
and inlines
Key: FOP-2809
URL: https://issues.apache.org/jira/browse/FOP-2809
Project: FOP
Issue Type: Bug
Components: layout/line
Affects Versions: 2.3
Reporter: Dan Caprioara
The text should be presented on two lines:
{quote}
line1 line1 line1 line1 LINE1
line2
{quote}
But is like this, on three lines.
{quote}
line1 line1 line1 line1
LINE1
line2
{quote}
The snippet:
{code:xml}
http://www.w3.org/1999/XSL/Format;
xmlns:fox="http://xmlgraphics.apache.org/fop/extensions; xml:lang="en-us">
line1 line1 line1 line1
LINE1
line2
{code}
If you add words to the example, you will see that it always add a break before
the second-to-last word.
If you remove the inline: {{line2}} and leave just the
{{line2}} text, this corrects the problem. The same if you remove the tags of
any inline.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FOP-2731) Position:fixed uses a bad reference area
[
https://issues.apache.org/jira/browse/FOP-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101599#comment-16101599
]
Dan Caprioara commented on FOP-2731:
Possible fix:
{code}
Index: BlockContainerLayoutManager.java
===
--- BlockContainerLayoutManager.java(revision 161373)
+++ BlockContainerLayoutManager.java(working copy)
@@ -744,7 +744,57 @@
}
return new Point(x, y);
}
+
+// PATCH START - FOP-2731 Using the page as reference for fixed
positioning
+
+/**
+ * Gets the offset of the box, when having a position: fixed.
+ * The reference area is the page.
+ *
+ * @return The coordinate in the page.
+ */
+private Point getFixedOffset() {
+int x = 0;
+int y = 0;
+
+if (abProps.left.getEnum() != EN_AUTO) {
+x = abProps.left.getValue(this);
+} else if (abProps.right.getEnum() != EN_AUTO
+&& width.getEnum() != EN_AUTO) {
+x = getPageWidth()
+- abProps.right.getValue(this) - width.getValue(this);
+}
+if (abProps.top.getEnum() != EN_AUTO) {
+y = abProps.top.getValue(this);
+} else if (abProps.bottom.getEnum() != EN_AUTO
+&& height.getEnum() != EN_AUTO) {
+y = getReferenceAreaForFixedBPD()
+- abProps.bottom.getValue(this) - height.getValue(this);
+}
+return new Point(x, y);
+}
+
+/**
+ * Gets the width of the page.
+ *
+ * @return the width of the page.
+ */
+public int getPageWidth() {
+ return (int) getCurrentPV().getViewArea().getWidth();
+}
+
+/**
+ * Gets the height of the page.
+ *
+ * @return the height of the page.
+ */
+protected int getReferenceAreaForFixedBPD() {
+ return (int) getCurrentPV().getViewArea().getHeight();
+}
+
+// PATCH END
+
/** {@inheritDoc} */
@Override
public void addAreas(PositionIterator parentIter, LayoutContext
layoutContext) {
@@ -884,14 +934,29 @@
viewportBlockArea.setCTM(absoluteCTM);
viewportBlockArea.setClip(needClip());
-if (abProps.absolutePosition == EN_ABSOLUTE
-|| abProps.absolutePosition == EN_FIXED) {
+
+// PATCH START - FOP-2731 Using the page as reference for fixed
positioning
+
+//if (abProps.absolutePosition == EN_ABSOLUTE
+//|| abProps.absolutePosition == EN_FIXED) {
+//Point offset = getAbsOffset();
+//viewportBlockArea.setXOffset(offset.x);
+//viewportBlockArea.setYOffset(offset.y);
+//} else {
+////nop
+//}
+if (abProps.absolutePosition == EN_ABSOLUTE) {
Point offset = getAbsOffset();
viewportBlockArea.setXOffset(offset.x);
viewportBlockArea.setYOffset(offset.y);
+} else if (abProps.absolutePosition == EN_FIXED) {
+Point offset = getFixedOffset();
+viewportBlockArea.setXOffset(offset.x);
+viewportBlockArea.setYOffset(offset.y);
} else {
//nop
}
+// PATCH END
referenceArea = new Block();
referenceArea.addTrait(Trait.IS_REFERENCE_AREA, Boolean.TRUE);
{code}
> Position:fixed uses a bad reference area
>
>
> Key: FOP-2731
> URL: https://issues.apache.org/jira/browse/FOP-2731
> Project: FOP
> Issue Type: Bug
> Components: layout/block
>Affects Versions: 2.2
>Reporter: Dan Caprioara
> Attachments: position-fixed-bad-reference-area.png
>
>
> When trying to place some elements to the corners of the page, it seems that
> FOP uses some wrong dimensions. Take a look at the attached screenshot,
> showing the difference between FOP and AntennaHouse.
> {code}
>
> xml:lang="dflt"
> xmlns:css="http://www.w3.org/1998/CSS;
> xmlns:fo="http://www.w3.org/1999/XSL/Format;>
>
>
> master-name="css2fo-default">
>
> blank-or-not-blank="any"
> master-reference="spm-css2fo-default"
> odd-or-even="any"
> page-position="any"/>
>
>
> master-name="spm-css2fo-default"
> page-height="8.27in"
> page-width="5.83in">
> border-bottom-color="orange"
> border-bottom-style="solid"
> border-bottom-width="2pt"
> border-left-color="orange"
>
[jira] [Created] (FOP-2731) Position:fixed uses a bad reference area
Dan Caprioara created FOP-2731:
--
Summary: Position:fixed uses a bad reference area
Key: FOP-2731
URL: https://issues.apache.org/jira/browse/FOP-2731
Project: FOP
Issue Type: Bug
Components: layout/block
Affects Versions: 2.2
Reporter: Dan Caprioara
Attachments: position-fixed-bad-reference-area.png
When trying to place some elements to the corners of the page, it seems that
FOP uses some wrong dimensions. Take a look at the attached screenshot, showing
the difference between FOP and AntennaHouse.
{code}
http://www.w3.org/1998/CSS;
xmlns:fo="http://www.w3.org/1999/XSL/Format;>
http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
http://ns.adobe.com/xap/1.0/;>oXygen PDF
Chemistry
An element with position: fixed is
positioned relative to its
page.
1. Normal div.
Fixed top left.
Fixed top right.
Fixed bottom left.
Fixed bottom right.
2. Normal div.
3. Normal div.
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (FOP-2704) Using the Google fonts Roboto font (updated 2017), java.lang.UnsupportedOperationException: coverage set class table not yet supported
Dan Caprioara created FOP-2704:
--
Summary: Using the Google fonts Roboto font (updated 2017),
java.lang.UnsupportedOperationException: coverage set class table not yet
supported
Key: FOP-2704
URL: https://issues.apache.org/jira/browse/FOP-2704
Project: FOP
Issue Type: Bug
Components: font/opentype
Affects Versions: 2.2, 2.1
Reporter: Dan Caprioara
Attachments: Roboto-Regular.ttf, Roboto-Thin.ttf
Steps:
# Download the Roboto TTF font from Google Fonts.
# Create a configuration file with a triplet pointing to the "roboto-regular"
or "roboto-thin" TTF file.
You get:
{code}
java.lang.UnsupportedOperationException: coverage set class table not yet
supported
at
org.apache.fop.complexscripts.fonts.GlyphClassTable$CoverageSetClassTable.(GlyphClassTable.java:262)
at
org.apache.fop.complexscripts.fonts.GlyphClassTable.createClassTable(GlyphClassTable.java:88)
at
org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEFMarkGlyphsTableFormat1(OTFAdvancedTypographicTableReader_Original.java:3344)
at
org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader.readGDEFMarkGlyphsTableFormat1(OTFAdvancedTypographicTableReader.java:69)
at
org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEFMarkGlyphsTable(OTFAdvancedTypographicTableReader_Original.java:3357)
at
org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readGDEF(OTFAdvancedTypographicTableReader_Original.java:3427)
at
org.apache.fop.complexscripts.fonts.OTFAdvancedTypographicTableReader_Original.readAll(OTFAdvancedTypographicTableReader_Original.java:80)
at
org.apache.fop.fonts.truetype.OpenFont.handleCharacterSpacing(OpenFont.java:786)
at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:755)
at
org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
{code}
There are two changes that should be done to the
{{OTFAdvancedTypographicTableReader}}.
# The method {{readGDEFMarkGlyphsTableFormat1}} should catch this exception
# The method {{constructLookupsLanguage}} should check if the {{languages}}
parameter is null.
After these changes, the PDF is produced and it looks good. I am not sure what
are the side effects on the font that is embedded into the PDF..
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (FOP-2701) Some of the latin ligatures make text not searchable in PDF
Dan Caprioara created FOP-2701:
--
Summary: Some of the latin ligatures make text not searchable in
PDF
Key: FOP-2701
URL: https://issues.apache.org/jira/browse/FOP-2701
Project: FOP
Issue Type: Bug
Components: font/opentype
Affects Versions: 2.1
Environment: Windows 10, Calibri font.
Reporter: Dan Caprioara
Attachments: latn-ligatures-Antenna-House.pdf, latn-ligatures-FOP.pdf
This problem happens using the Calibri font, that is packed in the MS Office
suite and Windows 10.
I tested with the following text: {{file settings}}.
The resulted PDF text contains ligatures: {{(fi)le se(tti)ngs}}
Searching for {{file}} in Acrobat Reader results in the first word being
selected. This is Ok. But searching for {{set}}, or {{settings}} gives no
results.
The same example, run with Antenna House works fine, you get results when
searching for {{settings}}.
Here is the complete FO file:
{code:xml}
http://www.w3.org/1999/XSL/Format;>
file
settings
{code}
Some considerations:
# A workaround would be to reject all the substitutions that are not part of
org.apache.fop.fonts.type1.AdobeStandardEncoding. This would leave the (fi)
ligature, but reject the (tti) one. But this seems to work only for Calibri and
not for Roboto!!
# I think there might be some issues with the font embedding, and some
substitution mapping data is lost. It is just a guess, I am not sure how PDF
deals with substitutions.
I know that setting in FO xml:lang to "en" disables the ligatures, but is not a
solution for my project. I would appreciate any suggestions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
