Re: [Maposmatic-dev] [PATCH] [ocitysmap] Rescale category header where needed

[Jeroen van Rijn]

On Tue, Apr 17, 2012 at 09:58, Thomas Petazzoni
<address@hidden> wrote:
> Hello Jeroen,
>
> Thanks a lot for contributing this. It's really nice to see that people
> outside of the original MapOSMatic core team are contributing code.

My pleasure. I have a few minor features needing a bit of cleanup, but
I'll contribute those as well after we get this bug closed. One of
them a new layout I needed for work last week, the other an additional
output format (Encapsulated Postscript) and an --ps-level option to
set the Postscript level 2/3 for .ps/.ps.gz/.eps.

Some other minor things and more substantial stuff will come down the line.

> Le Tue, 17 Apr 2012 03:18:17 +0200,
> Jeroen van Rijn <address@hidden> a écrit :
>
>> +        # Measure header text and rescale if needed
>> +        ctx.save()
>> +        # Tell Pango to not wrap text
>> +        layout.set_width(-1)
>
> Why? If I understand correctly, you want each category title to fit
> without being wrapped. Is this really what we want to do?

You understand correctly. I thought it would look better than having
the header wrap and extending the grey background. If it ends up
having to scale too much and render the header unreadable, or support
for true multi-line headers is added, this wrapping could be allowed.
Personally I thought it would look nicer to have the headers all the
same height, so if wrapping can be avoided, do it.

> Another question is that, if I'm not mistaken, you are doing this font
> size adaptation algorithm on a per-category title basis, which means
> that depending on their length, each title might have a different font
> size, which is not really pretty.

It's on a per category basis, indeed.

In my test with this patch so far only the Public buildings category
had to rescale to a modest 80%, the rest stayed at 100% It really
didn't look all that out of place. I've attached this result to the
bug just now.

But certainly, I'll render a larger area to draw in more amenities,
see what it looks like then.

> I think I would prefer a scheme where you first travel through all
> category titles, compute the maximum length, and then the adequate font
> size, which you then use to render all category titles.
>
> What do you think about this?

That I can do as well, sure. I'll work on factoring out this measuring
step so that the font computation can be done before each individual
category is drawn.

>> #1 A Dutch city, but with -L de_DE.UTF8. I only have the Dutch OSM
>> data installed at the moment on my dev system. I'm waiting for the
>> license change to have rolled over before importing the entire planet,
>> so I can have rolling updates.
>
> On my side, I directly use the GIS database we use for the production
> website through a SSH tunnel. Maybe we could later setup a mechanism to
> allow some trusted developers to also access this database for their
> testing/development?

I do appreciate the offer. It wouldn't have to be used in developing
new features, but as a separate .ocitysmap config to be used when
squashing bugs would mean we have a better chance of reproducing the
exact error.

Still, I'm likely going to set up a full mirror on my home server,
it's reasonably beefy. If I don't absolutely have to cause load on the
production DB, then it's better not to?

-- 
↑↑↓↓←→←→BA[Start]