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

[Jeroen van Rijn]

On Tue, Apr 17, 2012 at 13:35, Thomas Petazzoni
<address@hidden> wrote:
> Hello,
>
> Le Tue, 17 Apr 2012 12:17:12 +0200,
> Jeroen van Rijn <address@hidden> a écrit :
>
>> 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.
>
> Great. Just curious, by "for fork", you mean that you're somehow using
> ocitysmap in an professional context?

I did use it professionally as a one off. I needed a detailed map of a
city centre that could be imported into Corel Draw for my brother in
law to use for event planning. As I'm his IT guy and was already
somewhat familiar with ocitysmap from the translation side, I decided
to monkey patch it to add additional output options and an extra
layout (no grid, no shading - based on -l plain, but just the map,
title and copyright footer).

I can't really say if this will become a regular thing, using
ocitysmap for work. I was just glad to have it in arm's reach when I
needed it last week. :) If it becomes a regular thing I'll try and
wrangle some sponsoring, if nothing else to contribute some features
done in on hours instead of off hours.

Those patches (EPS, --ps-level, layout simple), if cleaned up, would
come from my work email. The majority of my interest in this project
is entirely personal. Basically I just happened to need something
map-wise for work and ocitysmap was the first thing that came to mind.

>> > 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.
>
> Ok. I guess we can try this way and see how it behaves. It's always
> possible to change our minds later on if we decide that a different
> strategy is better.

Certainly. It's just code, it can be changed if a better solution
comes along. I'm always more interested in seeing a particularly
suitable solution used than any particular piece of code.

>> > 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.
>
> Hum, personally, I find it a bit strange to have different sizes for
> the headers, after seeing your example. Maybe we can wait for the input
> of others (David, Étienne, and others) to decide what to do.

Upon rendering a larger area that had headers come after the category
in question, it turns out that the rescaled font didn't reset to the
original point size. So instead of remedying this and allowing
individual headers to be rescaled as needed properly, I was thinking I
might as well go with your plan of measuring first, computing an
overall scale factor and then sending off all the drawing calls.

>> 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.
>
> Right. I personally also use it during development.
>
>> 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?
>
> Sure, if you have another way, that's fine. But the GIS database is
> quite heavy and complicated to maintain, so if we can ease the
> developer's work by removing the burden of maintaining the GIS
> database, it'd be nice.

Understood and appreciated. I'd certainly take you up on the offer to
have a 2nd configuration to use when targeting a specific bug, so
we're all on the same page. However I do have additional uses for a
full GIS database beyond maposmatic developement that I want to
eventually tackle, so I don't mind the administrative burden.

Best regards,
Jeroen.

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