[jira] [Resolved] (FOP-3139) Add support for font-selection-strategy=character-by-character
[ https://issues.apache.org/jira/browse/FOP-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner resolved FOP-3139. Fix Version/s: main Resolution: Fixed https://github.com/apache/xmlgraphics-fop/commit/b16022ece329197f72f47943085d45b56e26806e > Add support for font-selection-strategy=character-by-character > -- > > Key: FOP-3139 > URL: https://issues.apache.org/jira/browse/FOP-3139 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Fix For: main > > Attachments: test2.fo > > > fop test.fo out.pdf > All glyphs should map to a font -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3139) Add support for font-selection-strategy=character-by-character
[ https://issues.apache.org/jira/browse/FOP-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3139: --- Description: fop test.fo out.pdf All glyphs should map to a font > Add support for font-selection-strategy=character-by-character > -- > > Key: FOP-3139 > URL: https://issues.apache.org/jira/browse/FOP-3139 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: test2.fo > > > fop test.fo out.pdf > All glyphs should map to a font -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FOP-3139) Add support for font-selection-strategy=character-by-character
[ https://issues.apache.org/jira/browse/FOP-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Steiner updated FOP-3139: --- Attachment: test2.fo > Add support for font-selection-strategy=character-by-character > -- > > Key: FOP-3139 > URL: https://issues.apache.org/jira/browse/FOP-3139 > Project: FOP > Issue Type: Bug >Reporter: Simon Steiner >Assignee: Simon Steiner >Priority: Major > Attachments: test2.fo > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FOP-3139) Add support for font-selection-strategy=character-by-character
Simon Steiner created FOP-3139: -- Summary: Add support for font-selection-strategy=character-by-character Key: FOP-3139 URL: https://issues.apache.org/jira/browse/FOP-3139 Project: FOP Issue Type: Bug Reporter: Simon Steiner Assignee: Simon Steiner -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Character-by-character font selection strategy
Dongsheng, looks like you'll have to wait for proper character selection to be implemented - this should solve your problems. For now you could try to add a space between your characters and the rest of the word, or use a full unicode font such as DejaVu. Max Dongsheng Song schrieb: Did you mean this example[1] ? It great increase the fo file size, and I use DocBook, don't know how to use this feather in xsl, can you give me some advice ? [1] http://www.zvon.org/HowTo/Output/FOP0.18.1_examples_character.php Dongsheng Song 2009/1/16 Max Berger m...@berger.name: there is: please use fo:character, which should work just as expected. -- http://max.berger.name/ OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700 signature.asc Description: OpenPGP digital signature
Re: Character-by-character font selection strategy
Dear Dongsheng Song, the patch you refer to is outdated and the issue of character handling has changed since your quoted messages. I have just now updated the Wiki to reflect the changes. Please email back to the list if anything is unclear. Max Dongsheng Song schrieb: II have been googled the discuss[1,2], and Max Berger's patch[3], and the wiki[4]. The patch or wiki is too old, not apply to the trunk. What's the current status, can someone update it ? I [1] http://marc.info/?t=11829738402r=1w=2 [2] http://marc.info/?t=11780260132r=1w=2 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=39422 [4] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy Dongsheng Song -- http://max.berger.name/ OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700 signature.asc Description: OpenPGP digital signature
Re: Character-by-character font selection strategy
The wiki[2] same as web[1] for 'Font Selection Strategies'. But 'Word-by-Word' can't meet my case. For string '#xB2E2;#xCAD4;teststring', if I specify font-family=Times, SimSun, FOP paint using Times characters, not SimSun, so I got missing glyphs. I's there a way treat a single Chinese char(e.g. '#xB2E2') as a word ? [1] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy [2] http://xmlgraphics.apache.org/fop/trunk/fonts.html#selection 2009/1/15 Max Berger m...@berger.name: Dear Dongsheng Song, the patch you refer to is outdated and the issue of character handling has changed since your quoted messages. I have just now updated the Wiki to reflect the changes. Please email back to the list if anything is unclear. Max Dongsheng Song schrieb: II have been googled the discuss[1,2], and Max Berger's patch[3], and the wiki[4]. The patch or wiki is too old, not apply to the trunk. What's the current status, can someone update it ? I [1] http://marc.info/?t=11829738402r=1w=2 [2] http://marc.info/?t=11780260132r=1w=2 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=39422 [4] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy Dongsheng Song -- http://max.berger.name/ OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700
Re: Character-by-character font selection strategy
Dongshen, there is: please use fo:character, which should work just as expected. hth Max Am 15.01.2009 15:02, schrieb Dongsheng Song: The wiki[2] same as web[1] for 'Font Selection Strategies'. But 'Word-by-Word' can't meet my case. For string '#xB2E2;#xCAD4;teststring', if I specify font-family=Times, SimSun, FOP paint using Times characters, not SimSun, so I got missing glyphs. I's there a way treat a single Chinese char(e.g. '#xB2E2') as a word ? [1] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy [2] http://xmlgraphics.apache.org/fop/trunk/fonts.html#selection 2009/1/15 Max Bergerm...@berger.name: Dear Dongsheng Song, the patch you refer to is outdated and the issue of character handling has changed since your quoted messages. I have just now updated the Wiki to reflect the changes. Please email back to the list if anything is unclear. Max Dongsheng Song schrieb: II have been googled the discuss[1,2], and Max Berger's patch[3], and the wiki[4]. The patch or wiki is too old, not apply to the trunk. What's the current status, can someone update it ? I [1] http://marc.info/?t=11829738402r=1w=2 [2] http://marc.info/?t=11780260132r=1w=2 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=39422 [4] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy Dongsheng Song -- http://max.berger.name/ OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700
Re: Character-by-character font selection strategy
Did you mean this example[1] ? It great increase the fo file size, and I use DocBook, don't know how to use this feather in xsl, can you give me some advice ? [1] http://www.zvon.org/HowTo/Output/FOP0.18.1_examples_character.php Dongsheng Song 2009/1/16 Max Berger m...@berger.name: there is: please use fo:character, which should work just as expected.
Re: Character-by-character font selection strategy
II have been googled the discuss[1,2], and Max Berger's patch[3], and the wiki[4]. The patch or wiki is too old, not apply to the trunk. What's the current status, can someone update it ? I [1] http://marc.info/?t=11829738402r=1w=2 [2] http://marc.info/?t=11780260132r=1w=2 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=39422 [4] http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy Dongsheng Song
Re: Character-by-character font selection strategy
Dear Fop-Devs, I've started some work on that in a patch I've submitted a while ago (which needs cleanup - lots of cleanup) http://issues.apache.org/bugzilla/show_bug.cgi?id=39422 I've also implemented character-by-character font selection for JEuclid, which may serve as a reference. Please look at: http://jeuclid.sourceforge.net/jeuclid-core/xref/net/sourceforge/jeuclid/elements/support/text/StringUtil.html#102 http://jeuclid.sourceforge.net/jeuclid-core/xref/net/sourceforge/jeuclid/elements/support/attributes/MathVariant.html#194 I'll add all three links to the wiki. Of course the algorithms would have to be modified to work with fop's font system instead of AWTs. I'd be very willing to test / enhance a patch, because I really need this feature (hence my original patch). One quick wish while you're at it: AFAIK FOP still does not even print a warning when it replaces a character with the # sign. Please fix this! (Part of the patch). mfG Max Berger e-mail: [EMAIL PROTECTED] -- OpenPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me and my work please see http://max.berger.name signature.asc Description: OpenPGP digital signature
Re: Character-by-character font selection strategy
On Jun 28, 2007, at 18:32, Andreas L Delmelle wrote: ... calls an implementation of FontInfo.fontLookup() that just returns the first family in the list... Of course this should be supplemented: ... that is supported in the current configuration.
Character-by-character font selection strategy
I see there was a recent thread on fop-user called Mixing Languages and Unicode. I have the same problem. The PDFs that I create with FOP could potentially contain any mix of languages and no one font will support them all. I do not believe it is practical to try to implement a character-by- character font selection strategy in XSLT, even if I could figure out how to do it. Nor do I believe it is practical to try to create some custom font that supports all languages and embed that in all my PDFs. So my question is, what would it take to implement support for the font-selection-strategy property? Has anyone looked at this or taken a crack at it? Is there any chance that it might be implemented in the foreseeable future? Thanks, Loran Kary
Re: Character-by-character font selection strategy
On Jun 27, 2007, at 20:49, Loran Kary wrote: Hi, I see there was a recent thread on fop-user called Mixing Languages and Unicode. I have the same problem. The PDFs that I create with FOP could potentially contain any mix of languages and no one font will support them all. I do not believe it is practical to try to implement a character-by- character font selection strategy in XSLT, even if I could figure out how to do it. Nor do I believe it is practical to try to create some custom font that supports all languages and embed that in all my PDFs. I agree. Implementing something like this in XSLT is indeed a complete waste here. As for custom fonts supporting all possible Unicode-characters, they tend to blow up the resulting PDF's size when embedded... Font-selection is precisely why --I think-- the Recommendation states that in the first step of formatting, all 'characters are converted in character FOs' (in 1.1.2 Formatting). One could even argue that FOP is not compliant to the Rec here, as it treats contiguous blocks of text in the source XML internally as one character array. So my question is, what would it take to implement support for the font-selection-strategy property? Now, /there/ is a GOOD question to ask first! 8-) Always make /us/ think about that first, before nagging about possible plans to implement. Nice strategy. I like your style. :-) Come to think of it, a little understanding of FOP's internals and the implied Java-knowledge should be enough. No need to touch the layoutengine for this, if I judge correctly. We could implement this at the point where the FOText instances are processed, since the font- family info is already available at that point (and hence, there is the possibility to check for codepoints that have no glyph). We could do a substitution to character FO's for codepoints outside the default font's mapping... Cheers Andreas
Re: font-selection-strategy
I must say (from a pure FOP-POV), that I'm looking forward to see what Vincent will come up with with your help. WRT font-selection-strategy I believe that character-by-character will be a huge step forward for our two FO processors and should cover 98% of all use cases. If anyone needs more we can always look at it when this happens. I wouldn't think too much about that, yet, especially since we don't know the exact requirements that would come up. But I fully share your interpretation of the issues here. On 09.09.2005 19:54:38 Victor Mote wrote: FOP-devs: WRT font-selection-strategy, I think the new aXSL methods provide the means to client applications to implement the character-by-character option. My current reading of the spec is that the auto option is merely an opportunity, a hook if you will, for an implementation to do something fancier than character-by-character. This whole attribute is actually an extension to CSS, which only does character-by-character. The definition of auto is The selection criterion given by the contextual characters is used in an implementation defined manner. That seems to cover almost anything doesn't it? Including character-by-character. The Note under auto seems to confirm this. Nevertheless, the example given in the Note provides some ideas for other algorithms, and seems to suggest that there is room for more than one. So, the general framework would seem to include the definition of one or more such algorithms, naming each one, and then providing that name through some global-ish mechanism like a font-configuration file or other configuration option. The font system can then implement the algorithm, perhaps with the help of call-back methods to provide, for example, the various pieces of contextual text. Now, I suggest that the creation and definition of such algorithms should be driven by the user base. IOW, if a user wishes to suggest an algorithm for font-selection that provides something useful to them, it should be considered. I say this partly because I don't seem to have a need for any such thing. My general approach is going to be to provide a list of exactly one font-family and then (by perusing the log!!) make sure that font-family actually got used. If it did not, I'm going to consider my stylesheet to be deficient as opposed to the font selection algorithm. In other words, I am going to implement my own manual algorithm. The other wrinkle that the standard seems to present is qualitative judgments like better quality fonts and match each other badly stylistically. I know of no way to get this information other than asking the user for it. So it is likely that some algorithms will require additional information in font-configuration. This post does not require any response from anyone. I realize you are trying to get a release out the door. I just wanted to document my thoughts on the matter for you before they escaped. Victor Mote Jeremias Maerki
font-selection-strategy
FOP-devs: WRT font-selection-strategy, I think the new aXSL methods provide the means to client applications to implement the character-by-character option. My current reading of the spec is that the auto option is merely an opportunity, a hook if you will, for an implementation to do something fancier than character-by-character. This whole attribute is actually an extension to CSS, which only does character-by-character. The definition of auto is The selection criterion given by the contextual characters is used in an implementation defined manner. That seems to cover almost anything doesn't it? Including character-by-character. The Note under auto seems to confirm this. Nevertheless, the example given in the Note provides some ideas for other algorithms, and seems to suggest that there is room for more than one. So, the general framework would seem to include the definition of one or more such algorithms, naming each one, and then providing that name through some global-ish mechanism like a font-configuration file or other configuration option. The font system can then implement the algorithm, perhaps with the help of call-back methods to provide, for example, the various pieces of contextual text. Now, I suggest that the creation and definition of such algorithms should be driven by the user base. IOW, if a user wishes to suggest an algorithm for font-selection that provides something useful to them, it should be considered. I say this partly because I don't seem to have a need for any such thing. My general approach is going to be to provide a list of exactly one font-family and then (by perusing the log!!) make sure that font-family actually got used. If it did not, I'm going to consider my stylesheet to be deficient as opposed to the font selection algorithm. In other words, I am going to implement my own manual algorithm. The other wrinkle that the standard seems to present is qualitative judgments like better quality fonts and match each other badly stylistically. I know of no way to get this information other than asking the user for it. So it is likely that some algorithms will require additional information in font-configuration. This post does not require any response from anyone. I realize you are trying to get a release out the door. I just wanted to document my thoughts on the matter for you before they escaped. Victor Mote
