[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581324#comment-13581324
]
Chris Bowditch commented on FOP-2211:
-
Hi Alex,
I agree that Print Streams can get very large and holding them in memory is not
a good idea. Actually for cloud environments we don't plan to hold such files
in memory, but rather in a virtual file system, one that is ring fenced for
each tenant. Unlike a file system, where every tenant can see the files for
every other tenant on the system, the virtual file system protects against
this. The virtual file system is typically implemented using a Database.
Hopefully this helps clarifies our intentions from a requirements perspective.
I cannot comment on the lower level details.
Thanks,
Chris
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk
Attachments: fop.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2211) [PATCH] Fix improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581402#comment-13581402
]
Alexios Giotis commented on FOP-2211:
-
Hi Chris,
I don't understand the advantages of such a virtual file system or why would
anyone need to isolate the *temp* resources of different tenants that are using
a common filesystem. Are you afraid of collision on filenames ? Or that if the
application crashes, the temp files will not be deleted ?
Anyway, that would need going into more details about the use case and the
relevant cloud infrastructure. I will assume that you really have this need. I
will wait a few more days in case the initial authors (Peter and Mehdi) have
some more input. Then, I will update the 2 patches taking under consideration
the comments so far.
[PATCH] Fix improve the handling of temporary files using the new URI
resource resolvers
--
Key: FOP-2211
URL: https://issues.apache.org/jira/browse/FOP-2211
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: trunk
Reporter: Alexios Giotis
Fix For: trunk
Attachments: fop.patch, xgc.patch
As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
temp files has changed from:
{code}
File tmpFile = File.createTempFile();
// Write and read from the file
tmpFile.delete();
{code}
to:
{code}
File tmpFile = new File(System.getProperty(java.io.tmpdir),
counterStartingFrom1AsString);
tmpFile.deleteOnExit();
// Write and read from the file
{code}
This is fine when FOP is executed from the command line (which I guess this
is how most people use it) but it introduces a number of bad side effects for
long running processes that use FOP embedded.
1. Different FOP processes can't be executed in parallel on the same system
because creating the same temp file fails.
2. If the JVM is not normally terminated, the temp files are never deleted
and the next invocation of the JVM fails to run.
3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
files both on disk and a reference in memory.
There should not be a need to implement a custom resource resolver when using
FOP embedded in order to fix those issues. The default implementation should
work at least as good as it worked in FOP 1.1 or earlier.
Attached are 2 patches, one for XGC and one for FOP that should fix and
improve the handling of at least the temporary files.
For reference, [1] lists some reasons for implementing the new URI resource
resolvers.
[1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2213) Kerning is no longer applied
[
https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581630#comment-13581630
]
Vincent Hennebert commented on FOP-2213:
If a font provides a kern table but no 'kern' feature in the GPOS table, then
the kern table should be used as a fallback, as indicated at
http://www.microsoft.com/typography/otspec/recom.htm:
When a kern table and GPOS table are both present in a font, and an OFF layout
engine is requested to apply kerning to a run of text of a particular script
and language system: (a) If the number of kern feature lookups in the resolved
language system in the GPOS table is zero, then the kern table should be
applied, followed by any remaining GPOS features requested.
Also, the original font I used was DejaVu Sans [1], that does have a 'kern'
feature in its GPOS table. But because FOP finds no match for the script
('latn') and language ('dflt') that it computes from the FO file, it doesn't
apply it. Actually, it will apply it only if I specify one of the languages
listed under the 'latn' table, for example, 'ROM' for Romanian. Except that the
'language' XSL-FO property does not accept an OpenType language system tag, but
a language tag that conforms to ISO 639-1 (2-letter tag) or ISO 639-2 (3-letter
tag). And the ISO 639-2 tag for Romanian is 'ron' or 'rum', not 'ROM'. So it
seems that the code is lacking the lookup tables that will match an ISO 639
country tag to an OpenType language system tag. Also, IIUC a script table may
reference a default language system that should be used if no language is
specified, or if the particular language is not listed.
[1] http://dejavu-fonts.org/wiki/Main_Page
Kerning is no longer applied
Key: FOP-2213
URL: https://issues.apache.org/jira/browse/FOP-2213
Project: Fop
Issue Type: Bug
Components: fonts
Affects Versions: 1.1, trunk
Reporter: Vincent Hennebert
Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo,
kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo
See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph
as expected, while it's not the case with FOP 1.1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581665#comment-13581665 ] Glenn Adams commented on FOP-2213: -- Excellent sleuthing. I had missed that recommendation, the implementation of which should address this problem (in part). For the second part, regarding mapping of XSL-FO language and script value space into OT language and script tag space, I have been aware of this for a while, and had already opened FOP-2093 and FOP-2094 to address this problem. Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo, kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glenn Adams reassigned FOP-2213: Assignee: Glenn Adams Kerning is no longer applied Key: FOP-2213 URL: https://issues.apache.org/jira/browse/FOP-2213 Project: Fop Issue Type: Bug Components: fonts Affects Versions: 1.1, trunk Reporter: Vincent Hennebert Assignee: Glenn Adams Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo, kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph as expected, while it's not the case with FOP 1.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2093) explicit language may prevent gsub/gpos application
[ https://issues.apache.org/jira/browse/FOP-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581667#comment-13581667 ] Glenn Adams commented on FOP-2093: -- More generally, needs to map between the XSL-FO language value space and the OT language tag space. explicit language may prevent gsub/gpos application --- Key: FOP-2093 URL: https://issues.apache.org/jira/browse/FOP-2093 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Glenn Adams Assignee: Glenn Adams Need to ensure that if author specifies language='dflt' or language='' where '' effectively maps to the default language, but font does not list '', then gsub/gpos features will be used if applicable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2094) explicit script may prevent gsub/gpos application
[ https://issues.apache.org/jira/browse/FOP-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581668#comment-13581668 ] Glenn Adams commented on FOP-2094: -- More generally, needs to map between the XSL-FO script value space and the OT script tag space. explicit script may prevent gsub/gpos application - Key: FOP-2094 URL: https://issues.apache.org/jira/browse/FOP-2094 Project: Fop Issue Type: Bug Components: page-master/layout Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Glenn Adams Assignee: Glenn Adams Need to ensure that if author specifies script='dflt' or script='' where '' effectively maps to the default script, but font does not list '', then gsub/gpos features will be used if applicable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
