Quote:
Originally Posted by Sonist
But relying on a relatively primitive reader program is a good practice?! And better than relying on the composer of the data?!
I thing I am missing something here, or you did not read thibaulthalpern's post.
|
From what I read he's saying, he's saying here, I've got some data with the letters "fi" next to each-other in it. Now, because *I* think you're a human reader, and *I* think your fonts probably can't handle that, *I* am going to *change* that data to some strange glyph. But it's okay, because I'm relying on you to have *my* special software to re-render that glyph back into something human readable. But if you don't, your font may come up with something totally not readable. In any case, the original data is *gone* or hidden. This makes the data inscrutable to many devices unless they special case for such a glyph.
Now, it perfectly makes sense for a specialized reader software, if it suspects a font problem, to make this substition at the display level. It makes very little sense for the *composer* software to do so, changing the data before it's written into a certain format. Even if the format didn't change the data but merely provided some suggestion of an alternative data set, I would be hesitant to say that's a good idea; not only does it cause data bloat, but could easily lead to more trouble trying to parse and display your idiosyncratic format.