[Qgis-developer] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed
kimaidou
kimaidou at gmail.com
Tue May 28 07:20:04 PDT 2013
2013/5/28 Marco Hugentobler <marco.hugentobler at sourcepole.ch>
> >So for me, simply removing the adjustSizeToText call would be enough.
> Or we have to make sure this method does the job correctly, which may be a
> bit hard to implement : we need to avoid to have >collision with other
> composition items, etc.
>
> The problem is if the client provided text does not fit into the
> predefined label box.
>
I agree, but it is better than "now", and quite logical to me : if the
content does not fit, only the part which fits is visible. This allows the
output PDF to be like the author wanted to, with the position and size of
each text box as set in the Composer. And above all, text wraps correctly
without dynamic resize. We could try to add an option "max length" for the
text boxes which could be advertised in the getCapabilities ? This way the
client could warn the user whenever he tries to use a text which too many
characters ?
> It would be good to combine dynamic resize capabilities with line breaks
> somehow.
>
I think dynamic resize should be used only if we can use it with line
breaks.Better respect the position and size defined by the user in QGIS
composer than having a text item which get so long that it get out of the
composer limits.
> I'm open for suggestions.
>
Thanks, and please forgive my english which sometimes prevents me from
souding moderate enough. I know that giving ideas is easy and developping
features is harder !
Some suggestions (I am thinking out loud...)
* new option with max text length, advertised in the getCapabilities
* linked text boxes. In softwares like Adobe Illustrator, or Scribus
(open-source), you can link serveral text boxes, so that the text is
written is the first box then in the linked one if the content does not fit
the first one.
* If "linked" text boxes is implemented, the killer feature would have to
dynamically generate new pages with linked text boxes so that all the
content is written in as many boxes as necessary to have the full content
written down.
Sincerely
Michael
>
> Marco
>
>
>
> On 28.05.2013 11:53, kimaidou wrote:
>
> Hi
>
> I just made a small test and commented the line
> currentLabel->adjustSizeToText();
> Then recompile QGIS master and tested it with a classical text box (not
> html rendered) with a long text.
>
> I personnaly prefer the behaviour when this method is not called : the
> text box keep the size set by the user in QGIS. And the text wraps when it
> reaches the right side of the Box. I even tried with "HTML rendered" on
> (and my fake X Server running), and it worked well too.
>
> At the contrary, when adjustSizeToText is used, the box is transformed in
> a one line box, which goes to the right of the entire composition (out of
> it) : text does not wrap.
>
> So for me, simply removing the adjustSizeToText call would be enough. Or
> we have to make sure this method does the job correctly, which may be a bit
> hard to implement : we need to avoid to have collision with other
> composition items, etc.
>
> Regards
> Michael
>
>
>
> 2013/5/28 René-Luc D'Hont <rldhont at gmail.com>
>
>> Hi Marco
>>
>>
>>> I guess yes. 'adjustSizeToText()' works for text, not html. Html
>>> support for composer label was added recently to the composer label class.
>>> Please adapt the relevant lines to work with html labels too.
>>
>>
>> I'll adapt it
>>
>>
>>>
>>> >Question for Marco, Why removed label, if the request doesn't define a
>>> value ? Why not used the default value ?
>>>
>>> The idea was that the web client has the possibility to remove an
>>> advertised text label completely if it is not used. E.g. if a composition
>>> defines a text item with id 'author', the web client can simply ignore it
>>> if it does not want to have author's name printed. Note that the labels
>>> without ids are not removed as they are considered to be fix, so not
>>> subject to client text replacement (original meaning of label id was that
>>> this text item is subject to text replacement by web client. Later, the id
>>> has been generalized as an id for every item type).
>>>
>>> Another possibility would be to remove the item only if the client gives
>>> an empty text and use the default text otherwise. What do you think?
>>>
>>
>>
>> I prefer to remove the label only if the user gives an empty text.
>> Can I do it ?
>>
>>
>> Regards,
>> René-Luc
>>
>>
>> On 27.05.2013 22 <27.05.2013%2022>:23, rldhont wrote:
>>
>>> Hi Marco and other devs,
>>>>
>>>> In src/mapserver/qgsconfigparser.cpp:530 we can read :
>>>>
>>>> //replace label text
>>>> foreach ( QgsComposerLabel *currentLabel, composerLabels )
>>>> {
>>>> QString title = parameterMap.value( currentLabel->id().toUpper() );
>>>>
>>>> if ( title.isEmpty() )
>>>> {
>>>> //remove exported labels not referenced in the request
>>>> if ( !currentLabel->id().isEmpty() )
>>>> {
>>>> c->removeItem( currentLabel );
>>>> delete currentLabel;
>>>> }
>>>> continue;
>>>> }
>>>>
>>>> currentLabel->setText( title );
>>>> currentLabel->adjustSizeToText();
>>>> }
>>>>
>>>> This code is used to draw composer label with value defined by the QGIS
>>>> WMS Server Request GetPrint.
>>>>
>>>> The bug defined in the issues #7894 http://hub.qgis.org/issues/7894 is
>>>> probably du to the method adjustSizeToText()
>>>> Someone can confim it ?
>>>>
>>>> Question for Marco, Why removed label, if the request doesn't define a
>>>> value ? Why not used the default value ?
>>>>
>>>> Regards,
>>>> René-Luc D'Hont
>>>> 3Liz
>>>> _______________________________________________
>>>> Qgis-developer mailing list
>>>> Qgis-developer at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>
>>>
>>>
>>> --
>>> Dr. Marco Hugentobler
>>> Sourcepole - Linux & Open Source Solutions
>>> Weberstrasse 5, CH-8004 Zürich, Switzerland
>>> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
>>> Technical Advisor QGIS Project Steering Committee
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole - Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerlandmarco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130528/47acd95e/attachment-0001.html>
More information about the Qgis-developer
mailing list