<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Wishlist: support FC_POSTSCRIPT_NAME" href="https://bugs.freedesktop.org/show_bug.cgi?id=38737#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Wishlist: support FC_POSTSCRIPT_NAME" href="https://bugs.freedesktop.org/show_bug.cgi?id=38737">bug 38737</a> from <a class="email" href="mailto:freedesktop@paul.sladen.org" title="Paul Sladen <freedesktop@paul.sladen.org>"> Paul Sladen</a> <pre>Akira, thanks for the update! One thought I'd like to add, regarding the synthesis of missing data; is that when it comes to /debugging/ font-related issue, a large percentage of the (invalid) issues relate to sythesis and substitution occuring in FC or the toolkits. It is often the difficulty in seeing past where the sythesis (or simplification) of data is occuring, that hampers the debugging. Thus, it might arguably be better to cleanly /fail/ if a request is made for a TT_ attribute that doesn't exist (such as TT_NAME_ID_PS_NAME), than to return something that wasn't or isn't there. Perhaps the printing issue highlighted (where synthesis of missing attributes is needed) could be covered with a helper function of something like ReturnUniqueNameAsPostscript(). Such a function() (or ENUM) could then return the TT_NAME_ID_PS_NAME if it exists, or make something up. But in both cases, without obscuring the ability of an application /that cares/ to uniquely query or get the raw data. Does that make sense? I'm happy to expand on the above if not.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>