I did my own investigation of the font files using version 0.4 of the
monospace. The Regular, Italic, and Bold are all 100% to-spec monospace
fonts. There is a small metrics bug in the Bold Italic which means it's
not quite a to-spec monospace font.
The odd thing is the applications which are
We regard .ttf as a binary distribution format. Editing it to make
modifications to a font (apart from the very lowest-level bit-flipping
in data tables) is pretty perverse and often unpleasant; you certainly
wouldn't want to edit the glyph outlines in a .ttf.
The lack of free tools capable of
The other option is to convert the legacy naming of the Medium so that
it's a stand-alone family (like the Light) rather than being the Light-Bold.
Dave
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Too many of these solutions stick out like a sore thumb - neither
retaining the rhythm of the capital strokes, not cohesively using the
features of the font. And then at the other end of the spectrum,
versions far too similar to a B to be clear. I do hope we're not hitting
an impasse.
Dave
Yes, I'm in complete agreement here - it needs to be clearly not an
SS, while still immediately indicating exactly that underlying
semantic to everyone who sees it. We also have the constraint that we
need to slot this into a monospace font. Contradictory requirements,
yes, but we can be as
There's really nothing more that I can add to this - I think you're
seeing things which simply aren't there. The various suggestions, of
which you feature only three, clearly indicate that they did not feel
constrained by the Fraktur form, and were actively seeking their own,
Roman, solution
I'm afraid this explanation jumps through hoops as unjustifiable as
those Tschichold used. Again conflating z and ezh, shifting characters
about for no apparent reason, and papering over a complete lack of
similarity in characters. Passing off a distorted 3 as an acceptable
Romanized ezh is
Some people seem to be reading too much into my description of ß as a
ligature. A ligature is the joining of any two or more characters -
whether the joined setting can be sensibly decomposed into its
constituent parts or not. The ampersand, of example, is a ligature, but
no-one would suggest
I'm not sure what you're arguing here. The 1903 Sulzbacher Form,
effectively a thorough romanization of ß, *is* intended to be derived
from a long-s+short-s ligature.
It's Fraktur forms which were almost invariably long-s+z or long-s+ezh
forms. It's on *this* point that Tschichold was flatly
A very clear description, but it simply doesn't match the form they are
promoting. It conflates a z with an ezh - two completely different
shapes, and makes reference to features which simply aren't present. I'd
go as far as to say it's a explanation as fallacious as Tschichold's.
A long-s-ezh
I'm afraid you're not correct - the modern ß *is* a straightforward,
compact, and clear ligature of long-s, short-s.
The fact that at some stages through history words were spelt otherwise
(s-s, s-z, s-ezh) doesn't detract from the origin of the *current* shape
of the character.
Dave
--
I think we're agreed that we should have *something* in that slot, but
not agreed that it necessarily be a strange and distorted big version
of ß. There is no harm in searching for a solution that's clear,
understood, sympathetic, and elegant.
I'm not a German speaker and even I find the
To be clear, I absolutely respect typographic diversity, and certainly
don't regard ß as a foreign particle. However, I also have respect for
the necessity, diversity, and history of ß, which is why I don't find
the Dresdner Form of the capital visually acceptable.
ß is a simple and elegant
Unicode's guidance on U+1E9E reads capital sharp s is intended for
typographical representations of signage and uppercase titles, and
other environments where users require the sharp s to be preserved in
uppercase. Overall, such usage is rare. In contrast, standard German
orthography uses the
You're right - we have no idea what diktats we're going to comply with
over the next decade, or how they will impact on the fonts and various
scripts. So, while we should constantly strive to keep the metrics
stable, I have no doubt that we will be forced to make changes to them -
either to
I'm not a designer, so I too am interested to see if it can be done in
an aesthetically pleasing way. :)
My view is that a good solution needs to not only fit the design of the
font, but also be immediately obvious to German readers as to what it
is, why it exists, and why we've done it.
The
This isn't an issue with the Ubuntu font, it's an issue with the version
of Unicode being supported by the character map. U+20B9 is new in
Unicode 6.0, which is still in draft. It was requested that the font be
new-Rupee-ready, which it is, though apps will still need to catch up to
know what
17 matches
Mail list logo
