You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xmlgraphics.apache.org by je...@apache.org on 2008/12/01 17:00:50 UTC
svn commit: r722108 -
/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Author: jeremias
Date: Mon Dec 1 08:00:50 2008
New Revision: 722108
URL: http://svn.apache.org/viewvc?rev=722108&view=rev
Log:
Added "minus" as an alternative for "hyphen" & Co.
Modified:
xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Modified: xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
URL: http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java?rev=722108&r1=722107&r2=722108&view=diff
==============================================================================
--- xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java (original)
+++ xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java Mon Dec 1 08:00:50 2008
@@ -5,9 +5,9 @@
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -16,7 +16,7 @@
*/
/* $Id$ */
-
+
package org.apache.xmlgraphics.fonts;
import java.io.BufferedReader;
@@ -190,7 +190,7 @@
'\u2022', // bullet
'\u2013', // endash
'\u2014', // emdash
- '~',
+ '~',
'\u2122', // trademark
'\u0161', '\u203a', '\u0153', '\u2022', '\u017e', '\u0178', // 0xA0
' ', '\u00a1', '\u00a2', '\u00a3', '\u00a4', '\u00a5',
@@ -223,24 +223,24 @@
*/
private static final String[] UNICODE_GLYPHS;
private static final String[] DINGBATS_GLYPHS;
-
+
private static final Map CHARNAME_ALTERNATIVES;
private static final Map CHARNAMES_TO_UNICODE;
-
+
static {
Map map = new java.util.TreeMap();
UNICODE_GLYPHS = loadGlyphList("glyphlist.txt", map);
DINGBATS_GLYPHS = loadGlyphList("zapfdingbats.txt", map);
CHARNAMES_TO_UNICODE = Collections.unmodifiableMap(map);
-
+
map = new java.util.TreeMap();
addAlternatives(map, new String[] {"Omega", "Omegagreek"});
addAlternatives(map, new String[] {"Delta", "Deltagreek"});
//fraction maps to 2044 (FRACTION SLASH) and 2215 (DIVISION SLASH)
addAlternatives(map, new String[] {"fraction", "divisionslash"});
//hyphen maps to 002D (HYPHEN-MINUS) and 00AD (SOFT HYPHEN)
- addAlternatives(map, new String[] {"hyphen", "sfthyphen", "softhyphen"});
+ addAlternatives(map, new String[] {"hyphen", "sfthyphen", "softhyphen", "minus"});
//macron maps to 00AF (MACRON) and 02C9 (MODIFIER LETTER MACRON)
addAlternatives(map, new String[] {"macron", "overscore"});
//mu maps to 00B5 (MICRO SIGN) and 03BC (GREEK SMALL LETTER MU)
@@ -268,14 +268,14 @@
addAlternatives(map, new String[] {"seven", "sevenoldstyle"});
addAlternatives(map, new String[] {"eight", "eightoldstyle"});
addAlternatives(map, new String[] {"nine", "nineoldstyle"});
-
+
//map currency signs from and to their respective "oldstyle" variant
addAlternatives(map, new String[] {"cent", "centoldstyle"});
addAlternatives(map, new String[] {"dollar", "dollaroldstyle"});
-
+
CHARNAME_ALTERNATIVES = Collections.unmodifiableMap(map);
}
-
+
private static void addAlternatives(Map map, String[] alternatives) {
for (int i = 0, c = alternatives.length; i < c; i++) {
String[] alt = new String[c - 1];
@@ -289,7 +289,7 @@
map.put(alternatives[i], alt);
}
}
-
+
private static String[] loadGlyphList(String filename, Map charNameToUnicodeMap) {
List lines = new java.util.ArrayList();
InputStream in = Glyphs.class.getResourceAsStream(filename);
@@ -326,15 +326,15 @@
String charName = line.substring(0, semicolon);
String rawUnicode = line.substring(semicolon + 1);
buf.setLength(0);
-
+
StringTokenizer tokenizer = new StringTokenizer(rawUnicode, " ", false);
while (tokenizer.hasMoreTokens()) {
String token = tokenizer.nextToken();
assert token.length() == 4;
buf.append(hexToChar(token));
}
-
- String unicode = buf.toString();
+
+ String unicode = buf.toString();
arr[pos] = unicode;
pos++;
arr[pos] = charName;
@@ -344,7 +344,7 @@
}
return arr;
}
-
+
private static char hexToChar(String hex) {
return (char)Integer.parseInt(hex, 16);
}
@@ -359,7 +359,7 @@
public static final String charToGlyphName(char ch) {
return stringToGlyph(Character.toString(ch));
}
-
+
/**
* Returns a String containing the Unicode sequence the given glyph name represents.
* @param glyphName the glyph name
@@ -372,7 +372,7 @@
if (period >= 0) {
glyphName = glyphName.substring(0, period);
}
-
+
//Step 2
StringBuffer sb = new StringBuffer();
StringTokenizer tokenizer = new StringTokenizer(glyphName, "_", false);
@@ -409,14 +409,14 @@
sb.append(sequence);
}
}
-
+
if (sb.length() == 0) {
return null;
} else {
return sb.toString();
}
}
-
+
/**
* Return the glyphname from a string,
* eg, glyphToString("\\") returns "backslash"
@@ -465,6 +465,6 @@
public static String[] getCharNameAlternativesFor(String charName) {
return (String[])CHARNAME_ALTERNATIVES.get(charName);
}
-
+
}
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Max Berger <ma...@berger.name>.
Vincent,
Vincent Hennebert schrieb:
> However, on this particular change I still don’t agree. Replacing hyphen
> with minus and vice-versa is likely to give an ugly result. Why not adding
> en dash and em dash while we’re at it? I’d rather add hyphentwo (U+2010)
> to the list of alternatives for hyphen. If there were a glyph name for
> non-breaking hyphen (U+2011) that would make sense to add it too. I can
> imagine a purist font designer who would create a glyph for hyphen
> (U+2010) and not for the disputed hyphen-minus (U+002D).
I guess beautyness and uglyness are a matter of opinion.
In this case, the alternative is not finding the character, which means
that fop would print an '#' in place of the hyphen. And in my point of
view "word - word" is more beautiful than "word # word".
However, I do see your point that not all substitutions make sense, and
especially the two-way relationship between glyphs may not be feasilble,
it would be better to provide an ordered replacement list for all
glyphs (in this case it would list all the hyphens first, and the minus
last). Maybe such a list can be found somewhere already developed (and
tested)?
> Vincent
Max
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi All,
Thanks for your comments.
Jeremias Maerki wrote:
> On 03.12.2008 11:48:40 Vincent Hennebert wrote:
> <snip/>
>>>> Plus, while it makes sense to replace
>>>> minus-sign with hyphen-minus when minus-sign is not available, the other
>>>> way around is not acceptable. Anyway, since in practice this will
>>>> probably never happen, the whole thing can probably be simplified.
>>> Not acceptable under whose authority? You're stating your opinion.
>> Under the authority of the Unicode standard as I understand it. In some
>> cases hyphen-minus may be interpreted as a minus sign (section 6.2,
>> “General Punctuation”), but the opposite appears nowhere.
>
> Ah, we're looking in different places. I'm looking in the code charts.
> Section 6.2 talks about the semantics of the characters, but I'm talking
> about glyph selection. I don't think that's the same. FOP has to
> interpret characters according to section 6.2 during layout but (IMO) when
> it comes to painting glyphs the semantics are not necessarily applicable
> if you try to provide fallbacks.
Being given a bit more context throughout this thread, and looking
further into the code, I now understand the intent of it, and it’s quite
sensible and reasonable to me. Especially since there may be several
glyph names for the same code point (e.g., mu and mu1).
However, on this particular change I still don’t agree. Replacing hyphen
with minus and vice-versa is likely to give an ugly result. Why not adding
en dash and em dash while we’re at it? I’d rather add hyphentwo (U+2010)
to the list of alternatives for hyphen. If there were a glyph name for
non-breaking hyphen (U+2011) that would make sense to add it too. I can
imagine a purist font designer who would create a glyph for hyphen
(U+2010) and not for the disputed hyphen-minus (U+002D).
Vincent
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 03.12.2008 11:48:40 Vincent Hennebert wrote:
<snip/>
> >> Plus, while it makes sense to replace
> >> minus-sign with hyphen-minus when minus-sign is not available, the other
> >> way around is not acceptable. Anyway, since in practice this will
> >> probably never happen, the whole thing can probably be simplified.
> >
> > Not acceptable under whose authority? You're stating your opinion.
>
> Under the authority of the Unicode standard as I understand it. In some
> cases hyphen-minus may be interpreted as a minus sign (section 6.2,
> “General Punctuation”), but the opposite appears nowhere.
Ah, we're looking in different places. I'm looking in the code charts.
Section 6.2 talks about the semantics of the characters, but I'm talking
about glyph selection. I don't think that's the same. FOP has to
interpret characters according to section 6.2 during layout but (IMO) when
it comes to painting glyphs the semantics are not necessarily applicable
if you try to provide fallbacks.
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Vincent Hennebert <vh...@gmail.com>.
Jeremias Maerki wrote:
> On 02.12.2008 18:40:21 Vincent Hennebert wrote:
<snip/>
>> (example: with {"zero", "zerooldstyle"} zero is added as a fall-back for
>> zerooldstyle and vice-versa). I’m not sure this is very useful anyway:
>> the usage of the method shows that the first glyph is a ‘common’ one,
>> likely to be found in any font.
>
> Bad luck, Vincent, as exactly these alternatives groups have been
> introduced for a font which did not contain "zero", only "zerooldstyle".
> http://markmail.org/message/koi5m2pfsrf32ud3
Hmmm. Sh*t ;-)
>> Plus, while it makes sense to replace
>> minus-sign with hyphen-minus when minus-sign is not available, the other
>> way around is not acceptable. Anyway, since in practice this will
>> probably never happen, the whole thing can probably be simplified.
>
> Not acceptable under whose authority? You're stating your opinion.
Under the authority of the Unicode standard as I understand it. In some
cases hyphen-minus may be interpreted as a minus sign (section 6.2,
“General Punctuation”), but the opposite appears nowhere.
> Hey, this is just a mechanism that tries to get a reasonable result if a
> glyph in a font is missing. If someone is not happy with the result,
> he's free to use a different font.
<snip/>
Vincent
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by The Web Maestro <th...@gmail.com>.
I think Jeremias change is a step in the right direction, but I also
appreciate the process.
Clay
On 12/3/08, Chris Bowditch <bo...@hotmail.com> wrote:
> Jeremias Maerki wrote:
>
>> On 02.12.2008 18:40:21 Vincent Hennebert wrote:
>
> FWIW, I am happy with the glyph substitution the way Jeremias has
> implemented it.
>
>>
>>>Hi Jeremias,
>>>
>>>Jeremias Maerki wrote:
>>>
>>>Plus, while it makes sense to replace
>>>minus-sign with hyphen-minus when minus-sign is not available, the other
>>>way around is not acceptable. Anyway, since in practice this will
>>>probably never happen, the whole thing can probably be simplified.
>>
>>
>> Not acceptable under whose authority? You're stating your opinion.
>>
>> Hey, this is just a mechanism that tries to get a reasonable result if a
>> glyph in a font is missing. If someone is not happy with the result,
>> he's free to use a different font.
>
> This is exactly the use case I'm concerned about. Font designers doing
> things the user doesn't expect. I think it would be unfortunate if FOP
> blindly followed a spec in this case at the detriment of the user. It's
> not easy to get a Font changed.
>
> Thanks,
>
> Chris
>
>
>
> ---------------------------------------------------------------------
> Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
--
Regards,
The Web Maestro
--
<th...@gmail.com> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> On 02.12.2008 18:40:21 Vincent Hennebert wrote:
FWIW, I am happy with the glyph substitution the way Jeremias has
implemented it.
>
>>Hi Jeremias,
>>
>>Jeremias Maerki wrote:
>>
>>Plus, while it makes sense to replace
>>minus-sign with hyphen-minus when minus-sign is not available, the other
>>way around is not acceptable. Anyway, since in practice this will
>>probably never happen, the whole thing can probably be simplified.
>
>
> Not acceptable under whose authority? You're stating your opinion.
>
> Hey, this is just a mechanism that tries to get a reasonable result if a
> glyph in a font is missing. If someone is not happy with the result,
> he's free to use a different font.
This is exactly the use case I'm concerned about. Font designers doing
things the user doesn't expect. I think it would be unfortunate if FOP
blindly followed a spec in this case at the detriment of the user. It's
not easy to get a Font changed.
Thanks,
Chris
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 02.12.2008 18:40:21 Vincent Hennebert wrote:
> Hi Jeremias,
>
> Jeremias Maerki wrote:
> > Hi Vincent,
> >
> > these alternatives are only taken as a last resort before mentioning
> > that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> > MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> > Otherwise, I wouldn't have made the change. The change is also not about
> > replacing minus for a hyphen, but for the other way around.
>
> Ah, so actually the purpose of the change is to add the possibility to
> use HYPHEN-MINUS in place of MINUS-SIGN? The commit message says the
> opposite.
Ok, so I'm guilty of writing a somewhat ambiguous commit message. I can
live with that.
> AFAICT Unicode does not list minus-sign to be related to hyphen-minus,
> rather the other way around. I don’t want to split hairs but since the
> confusion is very easy we have to be careful of what we’re saying.
>
> And as far as I understand from the code, for /every/ glyph in the
> table, all of the other glyphs are added as possible fall-back glyphs
That's right.
> (example: with {"zero", "zerooldstyle"} zero is added as a fall-back for
> zerooldstyle and vice-versa). I’m not sure this is very useful anyway:
> the usage of the method shows that the first glyph is a ‘common’ one,
> likely to be found in any font.
Bad luck, Vincent, as exactly these alternatives groups have been
introduced for a font which did not contain "zero", only "zerooldstyle".
http://markmail.org/message/koi5m2pfsrf32ud3
> Plus, while it makes sense to replace
> minus-sign with hyphen-minus when minus-sign is not available, the other
> way around is not acceptable. Anyway, since in practice this will
> probably never happen, the whole thing can probably be simplified.
Not acceptable under whose authority? You're stating your opinion.
Hey, this is just a mechanism that tries to get a reasonable result if a
glyph in a font is missing. If someone is not happy with the result,
he's free to use a different font.
> > I can of
> > course add a warning if an alternative glyph is used. But I guess some
> > people would find the warning welcome while others might find it a
> > nuisance. Can we get some additional opinions to reach an informed
> > decision, please?
> >
> > On 02.12.2008 12:22:29 Vincent Hennebert wrote:
> >> Hi Jeremias,
> >>
> >>> Author: jeremias
> >>> Date: Mon Dec 1 08:00:50 2008
> >>> New Revision: 722108
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=722108&view=rev
> >>> Log:
> >>> Added "minus" as an alternative for "hyphen" & Co.
> >> Why? minus has nothing to do with hyphen, and the result is likely to
> >> look terrible. I think I would prefer to have a warning rather than
> >> a silent replacement. Anyway, if a font doesn’t even define a glyph for
> >> hyphen, then I doubt it will define one for the true minus.
> >>
> >> <snip/>
> >>
> >> Vincent
> >
> >
> >
> > Jeremias Maerki
>
>
> Vincent
>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 -
/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by sp...@leverkruid.eu.
Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
> No, but that could easily be included in AbstractCodePointMapping where
> the substitution is controlled from. That would be easier to implement
> than an event in the event processing framework as
> AbstractCodePointMapping doesn't have access to the user agent. If we
> decide to make it an event (which is probably a bit cleaner), I probably
> have to change AbstractCodePointMapping a bit to make it a two-stage
> process (we can only return one result, a char, which is not suitable
> for indicating a substitution to the outside). That's the first decision.
> The second is the log level (for both approaches): DEBUG, INFO or WARN.
> I'd vote for DEBUG in this case.
I agree that events are best and that DEBUG is the right level. Simon
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> No, but that could easily be included in AbstractCodePointMapping where
> the substitution is controlled from. That would be easier to implement
> than an event in the event processing framework as
> AbstractCodePointMapping doesn't have access to the user agent. If we
> decide to make it an event (which is probably a bit cleaner), I probably
> have to change AbstractCodePointMapping a bit to make it a two-stage
> process (we can only return one result, a char, which is not suitable
> for indicating a substitution to the outside). That's the first decision.
> The second is the log level (for both approaches): DEBUG, INFO or WARN.
> I'd vote for DEBUG in this case.
This may be of interest to the user, so I think an event is necessary.
DEBUG is fine I guess.
(That said, if that were me I wouldn’t do any glyph substitution at all.
If the user spent the time to specify ‘exotic’ glyphs, they’re likely to
have set up their system so that the suitable font is available, aren’t
they?)
> On 02.12.2008 16:49:42 spepping wrote:
>> Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
>>
>>> Hi Vincent,
>>>
>>> these alternatives are only taken as a last resort before mentioning
>>> that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
>>> MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
>>> Otherwise, I wouldn't have made the change. The change is also not about
>>> replacing minus for a hyphen, but for the other way around. I can of
>>> course add a warning if an alternative glyph is used. But I guess some
>>> people would find the warning welcome while others might find it a
>>> nuisance. Can we get some additional opinions to reach an informed
>>> decision, please?
>> Are such substitutions debuggable? If you set the log level high
>> enough, do you then get messages for each substitution? I guess that
>> sometimes that may come in handy for users who wonder why they do not
>> get the glyphs they expect.
>>
>> Simon
>>
>>> Jeremias Maerki
>
>
> Jeremias Maerki
Vincent
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
No, but that could easily be included in AbstractCodePointMapping where
the substitution is controlled from. That would be easier to implement
than an event in the event processing framework as
AbstractCodePointMapping doesn't have access to the user agent. If we
decide to make it an event (which is probably a bit cleaner), I probably
have to change AbstractCodePointMapping a bit to make it a two-stage
process (we can only return one result, a char, which is not suitable
for indicating a substitution to the outside). That's the first decision.
The second is the log level (for both approaches): DEBUG, INFO or WARN.
I'd vote for DEBUG in this case.
On 02.12.2008 16:49:42 spepping wrote:
> Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
>
> > Hi Vincent,
> >
> > these alternatives are only taken as a last resort before mentioning
> > that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> > MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> > Otherwise, I wouldn't have made the change. The change is also not about
> > replacing minus for a hyphen, but for the other way around. I can of
> > course add a warning if an alternative glyph is used. But I guess some
> > people would find the warning welcome while others might find it a
> > nuisance. Can we get some additional opinions to reach an informed
> > decision, please?
>
> Are such substitutions debuggable? If you set the log level high
> enough, do you then get messages for each substitution? I guess that
> sometimes that may come in handy for users who wonder why they do not
> get the glyphs they expect.
>
> Simon
>
> > Jeremias Maerki
>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 02.12.2008 14:50:12 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > On 02.12.2008 13:51:06 Chris Bowditch wrote:
> >
>
> <snip/>
>
> >>I think making the whole SVG Text process more transparent would
> >>really help as it seems quite mystical. I know you made some further
> >>notes on this process yesterday, but some more details about Font
> >>substitution and glyph relations would be useful.
> >
> >
> > That stuff is not mystical, just complicated because by now we have so
> > much functionality and support so many different output formats which
> > all have slightly different facilities. Furthermore, when I refactored
> > the SVG/PDF text painting I didn't have enough time to improve Batik's
> > font support so we it would be possible to plug FOP's font support into
> > Batik. Add to that the fact that, for example, PostScript and AFP still
> > have inferior text handling for SVG graphics which causes a higher
> > percentage of SVG text to be painted as shapes.
> >
> > I'm not sure how to make the documentation much clearer. Font
> > substitution itself is well documented. I'm hesitant to go in the
> > details of glyph relations because the best approach would be to
> > document all the substitutions we make and if that data is not generated
> > from the same source as the functionality in the code we always risk
> > losing synchronization. And that's a lot of work for little gain.
>
> You mentioned that Dialog gets translated to Times, why that happens is
> not clear to me. If there are a set of hard coded Font substitutions
> then they should be documented. If it's something the AWT classes do
> then a sentence that says Fonts may be substituted as per rules
> documented in X would be helpful.
There's not much hard-coding, except for the few font family names for
the base 14 fonts which can be overwritten. In your particular case,
you've had an explicit font substitution in your configuration file:
<substitution>
<from font-family="Dialog"/>
<to font-family="Times"/>
</substitution>
That's the sole reason why Dialog was substituted by Times. "Times" in
that case was then mapped to the base 14 Times font.
I've listed the hard-coded font mappings in FOP's documentation.
> You misunderstood me when I said to document glyph substitutions. I was
> thinking more along the lines of a sentence that said "glyphs are
> subject to substitution as per the Unicode standard Annex 14 <link/>" or
> similar.
Ah, but that would be a wrong thing to say as a general expression
because we've only registered a dozen or so hard-coded glyph
substitution groups in XGC. I made a note in FOP's documentation.
HTH
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> On 02.12.2008 13:51:06 Chris Bowditch wrote:
>
<snip/>
>>I think making the whole SVG Text process more transparent would
>>really help as it seems quite mystical. I know you made some further
>>notes on this process yesterday, but some more details about Font
>>substitution and glyph relations would be useful.
>
>
> That stuff is not mystical, just complicated because by now we have so
> much functionality and support so many different output formats which
> all have slightly different facilities. Furthermore, when I refactored
> the SVG/PDF text painting I didn't have enough time to improve Batik's
> font support so we it would be possible to plug FOP's font support into
> Batik. Add to that the fact that, for example, PostScript and AFP still
> have inferior text handling for SVG graphics which causes a higher
> percentage of SVG text to be painted as shapes.
>
> I'm not sure how to make the documentation much clearer. Font
> substitution itself is well documented. I'm hesitant to go in the
> details of glyph relations because the best approach would be to
> document all the substitutions we make and if that data is not generated
> from the same source as the functionality in the code we always risk
> losing synchronization. And that's a lot of work for little gain.
You mentioned that Dialog gets translated to Times, why that happens is
not clear to me. If there are a set of hard coded Font substitutions
then they should be documented. If it's something the AWT classes do
then a sentence that says Fonts may be substituted as per rules
documented in X would be helpful.
You misunderstood me when I said to document glyph substitutions. I was
thinking more along the lines of a sentence that said "glyphs are
subject to substitution as per the Unicode standard Annex 14 <link/>" or
similar.
Thanks,
Chris
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 02.12.2008 13:51:06 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > Hi Vincent,
> >
> > these alternatives are only taken as a last resort before mentioning
> > that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> > MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> > Otherwise, I wouldn't have made the change. The change is also not about
> > replacing minus for a hyphen, but for the other way around. I can of
> > course add a warning if an alternative glyph is used. But I guess some
> > people would find the warning welcome while others might find it a
> > nuisance. Can we get some additional opinions to reach an informed
> > decision, please?
>
> Thanks for the explanation. I was also thinking about this yesterday
> afternoon. I don't like the idea of the warning, because that makes
> users think there is something wrong when in fact there isn't but maybe
> an info level event instead to help make the process more transparent.
>
> Does this glyph relationship apply to XSL-FO and SVG Text or just SVG
> text?
It's the same for both XSL-FO and SVG as long as FOP's font library is
involved, i.e. for PDF, PS, AFP. But if for those formats stroked text
is used or if you're generating Java2D, TIFF/PNG or PCL, the SVG
production is completely in the hands of Batik. The behaviour can be
different. And Batik still doesn't use XML Graphics Commons.
> I think making the whole SVG Text process more transparent would
> really help as it seems quite mystical. I know you made some further
> notes on this process yesterday, but some more details about Font
> substitution and glyph relations would be useful.
That stuff is not mystical, just complicated because by now we have so
much functionality and support so many different output formats which
all have slightly different facilities. Furthermore, when I refactored
the SVG/PDF text painting I didn't have enough time to improve Batik's
font support so we it would be possible to plug FOP's font support into
Batik. Add to that the fact that, for example, PostScript and AFP still
have inferior text handling for SVG graphics which causes a higher
percentage of SVG text to be painted as shapes.
I'm not sure how to make the documentation much clearer. Font
substitution itself is well documented. I'm hesitant to go in the
details of glyph relations because the best approach would be to
document all the substitutions we make and if that data is not generated
from the same source as the functionality in the code we always risk
losing synchronization. And that's a lot of work for little gain.
> BTW, XEP does the same glyph substitution, so I guessed there must be
> some standard dictating this behaviour.
>
> Regards,
>
> Chris
>
> >
> > On 02.12.2008 12:22:29 Vincent Hennebert wrote:
> >
> >>Hi Jeremias,
> >>
> >>
> >>>Author: jeremias
> >>>Date: Mon Dec 1 08:00:50 2008
> >>>New Revision: 722108
> >>>
> >>>URL: http://svn.apache.org/viewvc?rev=722108&view=rev
> >>>Log:
> >>>Added "minus" as an alternative for "hyphen" & Co.
> >>
> >>Why? minus has nothing to do with hyphen, and the result is likely to
> >>look terrible. I think I would prefer to have a warning rather than
> >>a silent replacement. Anyway, if a font doesn’t even define a glyph for
> >>hyphen, then I doubt it will define one for the true minus.
> >>
> >><snip/>
> >>
> >>Vincent
> >
> >
> >
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> Hi Vincent,
>
> these alternatives are only taken as a last resort before mentioning
> that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> Otherwise, I wouldn't have made the change. The change is also not about
> replacing minus for a hyphen, but for the other way around. I can of
> course add a warning if an alternative glyph is used. But I guess some
> people would find the warning welcome while others might find it a
> nuisance. Can we get some additional opinions to reach an informed
> decision, please?
Thanks for the explanation. I was also thinking about this yesterday
afternoon. I don't like the idea of the warning, because that makes
users think there is something wrong when in fact there isn't but maybe
an info level event instead to help make the process more transparent.
Does this glyph relationship apply to XSL-FO and SVG Text or just SVG
text? I think making the whole SVG Text process more transparent would
really help as it seems quite mystical. I know you made some further
notes on this process yesterday, but some more details about Font
substitution and glyph relations would be useful.
BTW, XEP does the same glyph substitution, so I guessed there must be
some standard dictating this behaviour.
Regards,
Chris
>
> On 02.12.2008 12:22:29 Vincent Hennebert wrote:
>
>>Hi Jeremias,
>>
>>
>>>Author: jeremias
>>>Date: Mon Dec 1 08:00:50 2008
>>>New Revision: 722108
>>>
>>>URL: http://svn.apache.org/viewvc?rev=722108&view=rev
>>>Log:
>>>Added "minus" as an alternative for "hyphen" & Co.
>>
>>Why? minus has nothing to do with hyphen, and the result is likely to
>>look terrible. I think I would prefer to have a warning rather than
>>a silent replacement. Anyway, if a font doesn’t even define a glyph for
>>hyphen, then I doubt it will define one for the true minus.
>>
>><snip/>
>>
>>Vincent
>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>
>
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> Hi Vincent,
>
> these alternatives are only taken as a last resort before mentioning
> that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> Otherwise, I wouldn't have made the change. The change is also not about
> replacing minus for a hyphen, but for the other way around.
Ah, so actually the purpose of the change is to add the possibility to
use HYPHEN-MINUS in place of MINUS-SIGN? The commit message says the
opposite.
AFAICT Unicode does not list minus-sign to be related to hyphen-minus,
rather the other way around. I don’t want to split hairs but since the
confusion is very easy we have to be careful of what we’re saying.
And as far as I understand from the code, for /every/ glyph in the
table, all of the other glyphs are added as possible fall-back glyphs
(example: with {"zero", "zerooldstyle"} zero is added as a fall-back for
zerooldstyle and vice-versa). I’m not sure this is very useful anyway:
the usage of the method shows that the first glyph is a ‘common’ one,
likely to be found in any font. Plus, while it makes sense to replace
minus-sign with hyphen-minus when minus-sign is not available, the other
way around is not acceptable. Anyway, since in practice this will
probably never happen, the whole thing can probably be simplified.
> I can of
> course add a warning if an alternative glyph is used. But I guess some
> people would find the warning welcome while others might find it a
> nuisance. Can we get some additional opinions to reach an informed
> decision, please?
>
> On 02.12.2008 12:22:29 Vincent Hennebert wrote:
>> Hi Jeremias,
>>
>>> Author: jeremias
>>> Date: Mon Dec 1 08:00:50 2008
>>> New Revision: 722108
>>>
>>> URL: http://svn.apache.org/viewvc?rev=722108&view=rev
>>> Log:
>>> Added "minus" as an alternative for "hyphen" & Co.
>> Why? minus has nothing to do with hyphen, and the result is likely to
>> look terrible. I think I would prefer to have a warning rather than
>> a silent replacement. Anyway, if a font doesn’t even define a glyph for
>> hyphen, then I doubt it will define one for the true minus.
>>
>> <snip/>
>>
>> Vincent
>
>
>
> Jeremias Maerki
Vincent
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 -
/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by sp...@leverkruid.eu.
Quoting Jeremias Maerki <de...@jeremias-maerki.ch>:
> Hi Vincent,
>
> these alternatives are only taken as a last resort before mentioning
> that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
> MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
> Otherwise, I wouldn't have made the change. The change is also not about
> replacing minus for a hyphen, but for the other way around. I can of
> course add a warning if an alternative glyph is used. But I guess some
> people would find the warning welcome while others might find it a
> nuisance. Can we get some additional opinions to reach an informed
> decision, please?
Are such substitutions debuggable? If you set the log level high
enough, do you then get messages for each substitution? I guess that
sometimes that may come in handy for users who wonder why they do not
get the glyphs they expect.
Simon
> Jeremias Maerki
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Vincent,
these alternatives are only taken as a last resort before mentioning
that a glyph cannot be found. Unicode does list "minus" (Unicode: 2212,
MINUS-SIGN) to be related to "hyphen" (Unicode: 002D, HYPHEN-MINUS).
Otherwise, I wouldn't have made the change. The change is also not about
replacing minus for a hyphen, but for the other way around. I can of
course add a warning if an alternative glyph is used. But I guess some
people would find the warning welcome while others might find it a
nuisance. Can we get some additional opinions to reach an informed
decision, please?
On 02.12.2008 12:22:29 Vincent Hennebert wrote:
> Hi Jeremias,
>
> > Author: jeremias
> > Date: Mon Dec 1 08:00:50 2008
> > New Revision: 722108
> >
> > URL: http://svn.apache.org/viewvc?rev=722108&view=rev
> > Log:
> > Added "minus" as an alternative for "hyphen" & Co.
>
> Why? minus has nothing to do with hyphen, and the result is likely to
> look terrible. I think I would prefer to have a warning rather than
> a silent replacement. Anyway, if a font doesn’t even define a glyph for
> hyphen, then I doubt it will define one for the true minus.
>
> <snip/>
>
> Vincent
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: svn commit: r722108 - /xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/fonts/Glyphs.java
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Jeremias,
> Author: jeremias
> Date: Mon Dec 1 08:00:50 2008
> New Revision: 722108
>
> URL: http://svn.apache.org/viewvc?rev=722108&view=rev
> Log:
> Added "minus" as an alternative for "hyphen" & Co.
Why? minus has nothing to do with hyphen, and the result is likely to
look terrible. I think I would prefer to have a warning rather than
a silent replacement. Anyway, if a font doesn’t even define a glyph for
hyphen, then I doubt it will define one for the true minus.
<snip/>
Vincent
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org