<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br clear="all"><div>On Sun, Jun 9, 2013 at 11:28 AM, Tim Sutton <span dir="ltr"><<a href="mailto:lists@linfiniti.com" target="_blank">lists@linfiniti.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
I also think we should hide the old labelling dialog. I think Larry<br>
was working on migration logic that would allow old labels to be<br>
converted to new. I cant remember if he kept this back for 2.1 though.<br>
Assuming its not ready, we should follow Nathan's suggestion of hiding<br>
the old labels tab unless the project file indicates it is needed.<br></blockquote><div><br></div><div>I think the following need addressed before old labeling can be removed:<br><br></div><div>1) Method to do quick labeling (i.e., maybe bypass PAL's candidate creation and collision management).<br>
<br>As Borys pointed out, this is very important, even if not 'pretty,' for quick visualization of data. There are a couple of ways doing this that I see:<br><br></div><div>1a) Remove old labeling GUI, but *not* its functionality for 2.0 release. Instead, update the new GUI components to also be an interface for configuring old labeling, with a single parent combobox (a la symbology) to switch between Simple and Advanced. Then for 2.1, find a way to accomplish 1b). From the user's standpoint, the GUI doesn't necessarily change in this regard, i.e. there remains a 'simple' labeling option for layers.<br>
<br></div><div>1b) Update QgsPalLabeling/QgsPalLayerSettings and PAL to allow some form of bypassing of PAL, i.e. mimic old labeling's direct-to-paint text drawing, to offer a 'simple' labeling mode. GUI would then be updated to offer a 'simple' GUI mode as noted in 1a). Updating old projects is required, and old labeling can be totally dropped.<br>
<br></div><div>1c) Figure out the absolute fastest current settings to use to migrate old labeling over to. Do 2) and remove old labeling. Still introduce a 'simple' labeling mode, but it will not be as fast as old labeling until 1b) is implemented.<br>
<br></div><div>1d) Show old labeling dialog, when project uses it.<br></div><div><br>Any other options for 1) anyone can think of?<br><br></div><div>2) Migration routine for projects <= 1.8 to similar 'simple' drawing setup. For 1a) this would be done at the GUI-level. For 1b) and 1c) this means creating a migration routine to permanently move those old settings to new-style labeling (I have not worked on this yet).<br>
</div><div><br><br><div>My feelings/opinions for 1) and 2) are:<br><br></div><div>Having a 'Simple,' fast labeling mode will always have its advantages, regardless of how the labels are actually rendered by the backend, and especially as labeling becomes even more advanced and possibly even slower. The simple mode could just be a GUI filter that removes all but options similar to old labeling: text, buffer, and point-only placement. Behind the scenes, the method of painting the labels could eventually involve PAL, but probably initially just paint as per old labeling, under Advanced labeling (as is the case now).<br>
<br></div><div>Such a 'simple' mode should probably be the default when going to Vector Layer Properties -> Labels. Then, users can reasonably expect, or be appropriately warned, that Advanced options may be slower.<br>
</div><br>Option
1a) preserves old labeling speed and much of its GUI work is not
necessarily a dead end, but it does postpone the removal of old labeling
(which shouldn't happen unless there is an equal replacement, right?).
2) migration to labeling-ng settings could still happen and the changes
shown to user could still appear to have removed old labeling. <br><br>Option 1b) should be done, regardless. If done now, 2) is more of a permanent update process, rather than also having to do more in 2.1 release. This option will take the most time and it will require an unknown delay to 2.0 release, though maybe needs at least a week.<br>
<br></div><div>Option 1c) will result in unhappy users, especially on older hardware. Marco H's, and any further, PAL optimizations will definitely help here.<br><br></div><div>Option 1d) the easiest for 2.0 release, but pushes issue of removal of old labeling to 2.1, and (probably?) defaults to not using a fast labeling method for new projects, unless optimizations are done.<br>
</div><div><br></div><div>I would appreciate any PSC guidance, and any developer help, with regards to this 2.0 release issue.<br></div><div><br><br></div><div>3) Painting of text so that vector exports preserve text as text [0].<br>
<br>This is an important feature of old labeling that needs to exist in new labeling if old is to be removed. I have worked on this and have it exporting text again to SVG and PDF, though some issues with scale and resolution remain. Need to finish what I am currently working on first (see below).<br>
<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">
PS optimisation wise couldnt we just have a 'quick' mode that draws a<br>
maximum of n labels pre render?<br></blockquote><div><br></div><div>This was recently suggested here as well [1]. I see it as working like so:<br><br></div><div>* Divide number of to-be-labeled layers into desired absolute label limit.<br>
</div><div>* Set each layer's 'Number of features to label..' limit to the new absolute per-layer amount, unless it is already set lower.<br></div><div>* Maybe introduce a fast means of randomly choosing which features get labeled (a bit tricky because layers are labeled sequentially).<br>
</div><div><br></div><div>I think this should be on by default, and set to a reasonable limit (5000?), then the user can change it later, as a per-app and per-project setting. A message log notice can also be generated when the limit is reached.<br>
</div><div><br><br><div>What I am currently working on for labeling:<br><br></div>Fix
for issue #8003, "Font is not written to table when using change label
properties tool" [2]. Along the way to fixing that, I found a nasty
undocumented bug that accidentally allowed font substitutions (when
defined font is missing) to be saved to project. So, I've finally added
notifications to the user when a substitution has occurred.<br><br></div><div>Then, on to a serious attempt at finishing 3) [0]. Then, work on 1) and 2). Any help greatly appreciated, especially since my wife could have our second child any day now. :^)<br>
</div><div><br><br>[0] <a href="http://hub.qgis.org/issues/3975">http://hub.qgis.org/issues/3975</a><br>[1] <a href="http://hub.qgis.org/issues/4791#note-20">http://hub.qgis.org/issues/4791#note-20</a><br>[2] <a href="http://hub.qgis.org/issues/8003">http://hub.qgis.org/issues/8003</a><br>
<br></div><div>Regards,<br><br></div><div>Larry<br><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">
Regards<br>
<br>
Tim<br>
<br>
On Sun, Jun 9, 2013 at 2:36 PM, Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:<br>
> Marco Hugentobler is currently working on optimizing the labeling of<br>
> area features. Because it is feature-freeze I don't know if this will be<br>
> added to 2.0 or delayed for 2.1 - maybe the PSC can make a decision<br>
> about this.<br>
><br>
> Personally I would recommend to get rid of the old labeling now.<br>
><br>
> Andreas<br>
><br>
> Am 09.06.2013 12:47, schrieb Borys Jurgiel:<br>
>> The only thing I *REALLY* miss in the new labelling is an optional FAST method<br>
>> to put labels just in poligon centroids with ommiting any expensive collision<br>
>> algorithms. When just browsing data the speed is priority, I don't need<br>
>> beautiful map, I need to FAST put ANY labels to see what is in polygons.<br>
>><br>
>> Unless it's not available in the new labelling, we make a regression, removing<br>
>> one of the most fundamental features. Please correct me if I'm missed some PAL<br>
>> option that I can disable to achieve a significant boost.<br>
>><br>
>><br>
>> Dnia niedziela, 9 czerwca 2013 o 12:13:01 MORREALE Jean Roc napisał(a):<br>
>>> What is the status ? Are we going to keep a deprecated label tab for the<br>
>>> next 3 years ?<br>
>>><br>
>>> Le 26/05/2013 14:37, Nathan Woodrow a écrit :<br>
>>>> Can we finally remove the old label UI from the layer properties dialog?<br>
>>>><br>
>>>> Could we remove it by default and just enable it for old project that<br>
>>>><br>
>>>> have old labels defined.<br>
>>>><br>
>>>> - Nathan<br>
>>><br>
>>> _______________________________________________<br>
>>> Qgis-developer mailing list<br>
>>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> _______________________________________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
<br>
<br>
--<br>
Tim Sutton - QGIS Project Steering Committee Member (Release Manager)<br>
==============================================<br>
Please do not email me off-list with technical<br>
support questions. Using the lists will gain<br>
more exposure for your issues and the knowledge<br>
surrounding your issue will be shared with all.<br>
<br>
Visit <a href="http://linfiniti.com" target="_blank">http://linfiniti.com</a> to find out about:<br>
* QGIS programming and support services<br>
* Mapserver and PostGIS based hosting plans<br>
* FOSS Consulting Services<br>
Skype: timlinux<br>
Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>
==============================================<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div></div></div></div>