How do you address font engine rendering discrepancies among OSes? IIUC those discrepancies are a good reason most SVG export features convert everything into p

How do you address font engine rendering discrepancies among OSes? IIUC those discrepancies are a good reason most SVG export features convert everything into paths. Fun story-- awhile back some troglodytes living somewhere in the Linux font stack tripped some switch in their magical rendering engine. Whatever the change was, it caused even a mono-spaced font like DejaVu Sans Mono to have a significantly fatter width. So pre-trog Ubuntu perhaps would have X width for "Hello World This Should Fit Perfectly An SVG Rect" at size 10px, while post-trog Ubuntu would have X+7. For my SVG-based UI, this meant I had to do a startup feature test for pre or post-trog Linux and scale the font accordingly on post-trog machines to make sure it fit properly into the box. But honestly, I don't think you could do any kind of feature test like that with impunity. E.g., if the user created a page with no visible border lines drawn at the right edge of the text, they'd probably be surprised/irritated that the text is slightly scaled in a feeble attempt at cross-platform compatibility. Anyway, all these problems go away when the fonts are converted to paths-- the user simply sees static output based on the rendering engine on the dev's machine. Edit-- but of course if you convert to paths, you don't get text and text selection. Nevertheless, converting vector graphics output to SVG-with-text-content is not actually WYSIWYG, and that subtle truth will probably come back to bite your users.