DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #5 from Peter Hancock peter.hanc...@gmail.com 2010-01-21 07:35:10 UTC --- Created an attachment (id=24877) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24877) xdocs -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #6 from Peter Hancock peter.hanc...@gmail.com 2010-01-21 07:46:26 UTC --- The attachment 'xdocs' is the corresponding documentation update for the webserver -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #7 from Jeremias Maerki jerem...@apache.org 2010-01-21 08:01:33 UTC --- Thanks for your feedback. We're in agreement, it seems. (In reply to comment #4) snip/ I agree with all of your suggestions. Before you go ahead and commit I wonder how easy it is to configure fop to not embed the font. Is much dev work required do you think? In http://xmlgraphics.apache.org/fop/trunk/fonts.html it is claimed that not supplying an embed-url attribute directs fop not to embed the font, but this is not so, and in fact, fop never seems to have a chance at setting the embeddable flag on an AFP font. When AFPRendererConfigurator constructs the font instance it could set the flag then based on an attribute, but what other information is needed? When I manually set embeddable to false the rendered AFP only declares the font resource and the code page in the MCF structured field. I have not tried printing yet (Our afp printer is playing up for me today) or checked the spec to see if this is ok. If you happen to know that it should work we could perhaps add a boolean-like attribute to the font attribute (respected when type=CIDKeyed or all AFP?) and call AFPFont.setEmbeddable() upon creation (or pass a constructor arg). Otherwise I guess this would be a future unit work. AFP Font referencing should work via the mechanism described under: http://xmlgraphics.apache.org/fop/trunk/fonts.html#embedding (referenced-fonts) At least, I've tested that with outline and bitmap fonts at some point. However, we need to see what happens in the case of CIDKeyed because of the MapCodedFont object. I'll do a test. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jeremias Maerki jerem...@apache.org 2010-01-21 09:48:08 UTC --- I've applied your patches (documentation, too): http://svn.apache.org/viewvc?rev=901793view=rev Thanks for the patch! I've tested with referenced-fonts and that seems to do what I expect. The MapCodedFont gets generated and should work if the font and the codepage are installed on the target platform. Lacking a full AFP environment I cannot easily test that to the very end. The only thing I noticed is that the viewers don't recognize that the font is double-byte if the fonts are not embedded and not available to the editor. I've added a TODO in MapCodedFont with an idea which might help. In case you look into that class you may want to take a look. As for the Unicode blocks we use to determine whether we have to use the em space instead of a normal space for characters which don't provide individual metrics, I think we don't have all that we need, yet. I've stumbled over http://unicode.org/reports/tr11/ which mentions fullwidth and halfwidth characters. However, I could not yet find the location where the information for the destinction for each character can be found. With the font we tested with we got away since the em space equals the normal space increment. For fonts that have western characters, we may not get away with the current set of Unicode Blocks. Not knowing enough about eastern languages is a real impediment for me here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Sharing font code with FontBox
Not without a revamp of the font subsytem, I guess. I can't tell off-hand if FontBox would help us. There's quite some accumulated knowledge in our font subsystem with special cases for special fonts etc. which are important to preserve. Like Vincent I'm curious what Alexander Kiel has done. If it's easily possible to share, I guess that's a good thing. As usual it eventually takes an effort by someone to make it happen which is probably the biggest problem of all. On 18.01.2010 21:03:54 Simon Pepping wrote: From a FontBox report: We are still working on integrating Villu's patch which adds support for Adobe CFF/Type2 fonts to FontBox. This raises my question: Can we share font handling code with FontBox? Simon -- Simon Pepping home page: http://www.leverkruid.eu Jeremias Maerki
Re: Adding support for Arabic to FOP
On 16.01.2010 00:04:32 Jonathan Levinson wrote: Using PDF Vole to examine the PDF files and reading the PDF specification, I've come to the conclusion that PDF renderers such as Adobe Acrobat version 9.0 do not implement BIDI or glyph form shaping. Rather it is the job of the software that produces the PDF to ensure that the glyph drawing commands in left to right order pick the right glyphs and implement BIDI and paragraph line-breaking appropriately. Glyph form shaping (the choosing of the right glyphs for initial, intermediate and final forms) also has to be done by the software that produces the PDF. That's the impression I have, too. This means that adding Arabic support to FOP will involve at least the following areas: 1) Change of layout manager to support line-breaking on the left. 2) Integration of line-breaking in layout manager with BIDI algorithm to appropriately handle quoted strings. 3) Automatic recognition of right-to-left direction from UNICODE font rather than specifying text direction through writing-mode. 4) Implementation of form shaping glyph chooser in PDF rendering engine. 5) In PDF rendering engine - rearranging texts in Tj command so that they correspond to BIDI algorithm. Rearrangement has to be done on a character by character basis for instance Arabic text (rendered right to left) can contain numbers (rendered left to right) or quote French (rendered left to right). Not to forget the area tree (and intermediate formats) which has to support that. Keeping the door open to implement tb-lr is probably also something that should be kept in mind when tackling that. Best Regards, Jonathan Levinson Jeremias Maerki
DO NOT REPLY [Bug 48575] When generating EPS from SVG image content doesn't fit borders
https://issues.apache.org/bugzilla/show_bug.cgi?id=48575 --- Comment #4 from Paul Lysak paul.ly...@gmail.com 2010-01-21 14:31:21 UTC --- Hi Peter After some more investigation I've been able to render correct picture and it looks like the problem was not in FOP itself. I've been using Maven to add FOP to my project. With this configuration code the picture was wrong: dependency groupIdorg.apache.xmlgraphics/groupId artifactIdfop/artifactId version0.95/version /dependency After your comment I tried to use this configuration code and dependency groupIdorg.apache.xmlgraphics/groupId artifactIdfop/artifactId version0.95-1/version /dependency Strangle, but they both use the same jar file with FOP. Only difference is that 0.95-1 version (and, by the way, 0.93 and 0.94 versions too) in Maven repository declares dependencies on both avalon api and avalon impl: dependency groupIdorg.apache.avalon.framework/groupId artifactIdavalon-framework-api/artifactId version4.3.1/version /dependency dependency groupIdorg.apache.avalon.framework/groupId artifactIdavalon-framework-impl/artifactId version4.3.1/version /dependency and version 0.95 only declares dependency on avalon api (no dependency on avalon impl). But when i've been using version 0.95 there were no complains about missing classes - picture has rendered, but not correctly. So I wonder: can the problems with 0.95 be caused by incorrect packaging of some parts of xmlgraphics - something like old versions of classes which get overriden by including avalon impl jar? This question is the only remaining issue. Regards, Paul. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
