<div dir="ltr">Hi Tim,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 31, 2013 at 1:07 PM, Tim Sutton <span dir="ltr"><<a href="mailto:lists@linfiniti.com" target="_blank">lists@linfiniti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Larry<br><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 31, 2013 at 11:28 AM, Larry Shaffer <span dir="ltr"><<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andreas,<br><div><div class="gmail_extra"><br><div class="gmail_quote"><div>On Sat, Aug 31, 2013 at 2:43 AM, Andreas Neumann <span dir="ltr"><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</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"><div>Larry. I would suggest you take the time you need. The QGIS server is most of the time installed from source and is therefore not too tightly coupled with the official QGIS Desktop release.<br>
</div></blockquote><div><br></div></div><div>The bug (at least the main one, noted in the issue) is not in the mapserver code. It is definitely in QgsPalLabeling. I can fix it, but it screws up drop shadows and some other labeling components. However, I am at a complete loss as to why I am getting different font output resolutions between *servers*. Again, the only way to test this is to complete a reasonably extensive test suite, used across many platforms/setups. Otherwise, even reports from testers will be time-consuming to go over, without such a baseline for testing.<br>
</div><div><br></div><div>I really believe I can do this within the next week. Otherwise, I think it would be asking too much of the project to 'hold off' for another week beyond that.<br><br></div><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
Even if it is not installed from source it is relatively easy to publish QGIS server packages independent from Desktop.<br></div></blockquote><div><br></div></div><div>Not so on Mac, where it is included in the main app bundle. However, since William is the main distributor for the stable version, I suppose it could have a secondary release. My feeling is the bug should be reasonably squashed right now.<br>
</div><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"><div>
Btw: I dont see any of these font problems at my QGIS server installation. I would have noticed it since I use QGIS server quite extensively.<br></div></blockquote><div><br></div></div><div>I would love to know how that is possible. I've not seen a setup that doesn't exhibit the issue yet. Maybe it slight enough that you just don't 'see' it on manual visual inspection. Can you possibly run the current limited labeling server test from the build dir on that machine (or one with access to that web server)?<br>
<br>It is run individually with: ctest -R PyQgsPalLabelingServer -V<br><br>It should fail due to lack of configuration, but give info on setting up the local test server configuration file, e.g. [0]. Unfortunately, the misconfiguration, which causes the test class to be skipped, does not register as a FAIL at <a href="http://dash.orfeo-toolbox.org" target="_blank">dash.orfeo-toolbox.org</a>. Example of failed test, after local server configuration, for my Mac nightly build setup [1].<br>
<br></div><div>It should also definitely fail because the current control image is from Mac (font handling differences). Read the Python test file [2] to see other env vars you can set to create a new set of local control images for your platform (just don't commit them upstream to QGIS source, yet). You will need a set of control images for canvas too, since one of the test classes is to crosscheck server output against canvas's (the actual issue at hand), as well the comparison of expected server output.<br>
</div><div><br>[0] <a href="http://dash.orfeo-toolbox.org/testDetails.php?test=18860662&build=127142" target="_blank">http://dash.orfeo-toolbox.org/testDetails.php?test=18860662&build=127142</a><br>[1] <a href="http://dash.orfeo-toolbox.org/testDetails.php?test=18875858&build=127203" target="_blank">http://dash.orfeo-toolbox.org/testDetails.php?test=18875858&build=127203</a><br>
[2] <a href="https://github.com/qgis/Quantum-GIS/blob/master/tests/src/python/test_qgspallabeling_server.py" target="_blank">https://github.com/qgis/Quantum-GIS/blob/master/tests/src/python/test_qgspallabeling_server.py</a><br>
<br></div></div></div></div></div></blockquote><div><br></div><div>Personally I would prefer that we branch for release tomorrow night and not wait another week. The reason for this is that it would be good to allow enough time for a wide range of packages to be built from the release by the time FOSS4G comes, and that it would be nice to have the release well behind us by the time the upcoming hackfest starts. Also I am taking into account Andreas' comments above. Let me know tomorrow how things are looking and we can consider whether to extend the branching date by a few days to accommodate you.</div>
<div></div></div></div></div></blockquote><div><br></div><div>Ok. Thank you for the reply. I give you a report in 24 hrs. I, too, would very much prefer not to hold things up. I know many people are waiting and the timing is important as well.<br>
<br></div><div>Regards,<br><br></div><div>Larry<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">
<div>Regards</div><div><br></div><div>Tim</div><div><br></div><br></div></div></div></blockquote></div></div></div></div>