- From: Glenn Linderman <v+smufl@g.nevcal.com>
- Date: Sun, 5 Feb 2017 21:34:36 -0800
- To: public-music-notation-contrib@w3.org, John Schwartz <schwa@cockos.com>
On 2/2/2017 12:26 PM, Glenn Linderman wrote: > On 2/2/2017 9:06 AM, John Schwartz wrote: >> Hello group, >> >> By technical necessity or by design, the SMuFL/Bravura brace glyphs >> (0xE000, 0xE001) are equal in height to 5 staff lines. In the most >> typical use case, drawing a grand staff, that means the brace glyphs >> must be drawn with a font size 4-5x greater than all other glyphs. >> >> This causes a specific problem when drawing with Windows GDI, namely >> that GDI disables antialiasing above a certain font height, with no >> workaround. This means Bravura cannot be used, out of the box, with >> GDI. Screenshot here, GDI on the right: >> http://stash.reaper.fm/29696/svg-vs-otf.png >> >> (This is not about the merits or demerits of using GDI; the fundamental >> issue is that as far as I know, these are the only glyphs that are >> designed to be drawn at a radically different size from the rest, which >> creates at least one known problem. Also, I am aware that alternate >> brace glyphs are defined, but these do not address the problem, as they >> are the same height, but different aspect ratios.) >> >> I suggest adding new glyphs that could be used to composite a brace at >> various heights, similar to how 0xE003-0xE006 can be used to composite a >> square bracket at any height. Doing this for the brace would require >> adding at least 8 new glyphs: top, top-mid, mid-bottom, and bottom, for >> both left and right facing braces. Ideally multiple sets of >> compositable glyphs could be added for various brace heights. >> >> Best, >> John Schwartz >> Cockos Inc (REAPER) > > Sure Bravura can be used with GDI, it is just pixelated at large font > sizes. If you use technology that is 3 generations old, you get the > results of technology that is three generations old... or you have to > write code to work around the limitations. But you shouldn't expect > other people to write the code to work around the limitations. > > If you want higher-quality results, use newer technologies that provide > it. I don't want to write code to assemble characters from piece parts— > I did enough of that back in the bitmapped font days. > > If you want to build your new software, using new standard fonts, using > old technology, and build your characters out of piece parts, you can > read the curves out of the font description, and draw the characters > yourself, using lower-level primitives, using whatever anti-aliasing or > sub-pixel-filling algorithms you prefer. Or you can disassemble the > brace into its piece parts yourself, and make a special "brace piece > parts" font that you find produces suitable results using the technology > you prefer. > > So really, your question _is_ about the merits and demerits of using > GDI, because you are suggesting designing workarounds for old technology > into the new fonts. New technology doesn't need such workarounds. > > John, I skipped the whole GDI thing, so it really is old technology for me, but a thought popped into my head: does GDI have a way to scale things, as well as choose font sizes? So would adequate results be produced if you use a "maximum size that will get antialiased" and then scale it larger using transforms? Or does that still produce pixelated results?
Received on Monday, 6 February 2017 05:35:26 UTC