<div dir="ltr">Hi Matthias,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 11:29 PM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias.kuhn@gmx.ch" target="_blank">matthias.kuhn@gmx.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Larry,<br>
<br>
Thank you for this contribution.<br>
<br>
Do you have any experience yet to quantify the differences introduced by the various font rendering engines used on supported operating systems? I keep reading that they all render differently, but I haven't found a hint about how much that difference could be.<br>
</blockquote><div><br></div><div>No, I don't have any data on that. The results are currently too chaotic. This is why I think having a standard font available across all builds and tests is important.<br><br></div><div>
For example, when users submit to the tracker a labeling issue, a dev could ask them to ensure to post an example project using the standard test font. I think it would be good to have the standard font(s) also available as part of the install, like maybe in 'resources'. On Mac, the current issue is that custom fonts can no longer be loaded from a .qrc file, but still work if loaded from filesystem. <br>
<br></div><div>While too late to add to this release, I would like to implement the auto-loading of 'QGIS Vera Sans' on app startup by default, or at the very least have a 'Help->Load QGIS Vera Sans font' menu. The latter would allow users to quickly load the standard test font, and maybe others (when more are added); though, it doesn't help if the project being opened already references the font, i.e. best to auto-load on startup. Regardless, the user should not have to install those fonts onto their system.<br>
<br></div><div>Implementing something along these lines should help with gathering feedback on platform font inconsistencies from users, and for building a set of well-known rendering anomalies. Alternatively, we could add some basic renderchecker unit tests that specifically address platform font inconsistencies. It also might be handy to have a test report generator in the desktop app itself.<br>
<br>For example, a user could choose 'Help->Generate test report' and a test report directory is produced on the user's desktop and an index.html file opened in their browser to preview results. Such a report could provide a multitude of information, including lib dependency info, provider info, system info, and some specific renderchecker tests. If it were a PDF, then the images could be embedded and provide a simple format for sharing.<br>
</div><div><br></div><div>Regards,<br><br></div><div>Larry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers<span class=""><font color="#888888"><br>
Matthias<br>
</font></span></blockquote></div><br></div></div></div>