Have PrefSpacingAccents off by default #449

Open
moyogo opened this Issue Mar 19, 2013 · 5 comments

Projects

None yet

5 participants

@moyogo
moyogo commented Mar 19, 2013

Having PrefSpacingAccents on by default encourages bad practices.
If the combining diacritical marks are available in the font, with or without anchors, they should be used.
If they are not in the font, spacing accents will be used anyway.

Please stop encouraging the bad practice of using spacing accents instead of non-spacing one, have PrefSpacingAccents off by default.

@moyogo moyogo referenced this issue in fontforge/designwithfontforge.com Mar 19, 2013
Open

bad practices encouraged in Diacritics_and_Accents.md #8

@khaledhosny
Contributor

Furthermore, I see no reason to have that preference at all, if the font has combining accents just use them, if not fallback to the spacing ones and may be warn the user that his font lacks the combining accents (since both sets of accents usually have the same design this issue is merely philosophical, it makes no difference as regard to the composed glyphs being built, one can even reference unencoded glyphs for the accents).

@vernnobile vernnobile was assigned Mar 19, 2013
@vernnobile
Contributor

Yes. I will change the screenshot for the 'acute' anchor class to a non-contraversy mark. Also, please feel free to add to the designwithfontforge text if you can. It needs this sort of expert input, though bear in mind it is aimed at new users.
On a deeper level this is a philosophical issue and one not helped by the approach fontforge takes to 'easy diacritics'. Ideally, imo, fontforge should not build accented characters unless the true (non-spacing) marks exist in the font. If they don't exist fontforge should notify the user and create the appropriate empty unicode slots ready for the user to populate?
I'm curious about the original rationale for the 'PreferSpacingCharacters' option in accents preferences.

@ultrasquid

The rationale would be that in many 8-bit encodings, only the spacing
diacritics are available in the standard character set. It's a legacy
systems support issue, it would appear.

Also, I've raised a separate issue that these accent building parameters
should be carried with the individual font files and not in the application
preferences, as they may differ from font to font and get lost where they
currently are.

On Tue, Mar 19, 2013 at 6:53 AM, vernon adams notifications@github.comwrote:

Yes. I will change the screenshot for the 'acute' anchor class to a
non-contraversy mark. Also, please feel free to add to the
designwithfontforge text if you can. It needs this sort of expert input,
though bear in mind it is aimed at new users.
On a deeper level this is a philosophical issue and one not helped by the
approach fontforge takes to 'easy diacritics'. Ideally, imo, fontforge
should not build accented characters unless the true (non-spacing) marks
exist in the font. If they don't exist fontforge should notify the user and
create the appropriate empty unicode slots ready for the user to populate?
I'm curious about the original rationale for the 'PreferSpacingCharacters'
option in accents preferences.


Reply to this email directly or view it on GitHubhttps://github.com/fontforge/fontforge/issues/449#issuecomment-15115130
.

Jason Pagura
zimbach at gmail dot com

@vernnobile
Contributor

+1 the rationale of allowing building of fonts with small footprints, so suggest that the 'PreferSpacingCharacters' option should stay.
However, i think there's a good argument for upgrading the approach fontforge takes with diacritic characters.
My suggestion would be to introduce into the build accent characters tool, a system where the true diacritic marks are used as the default, and if they don't exist then the user is prompted to have them created. This would overtly enable 'good practice' as an integral way of creating type with fontforge. It would also be good opportunity to iron out some other stuff with diacritics in fontforge. Thoughts & comments??

@moyogo
moyogo commented Mar 20, 2013

If the option if off, the spacing characters are used when non-spacing characters are missing. It wouldn't break anything not keeping it as an option when working in 8-bit encodings since they don't have non-spacing diacritics, and if they did they should be used anyway even there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment