maposmatic-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Petazzoni
Subject: Re: [Maposmatic-dev] [PATCH] [ocitysmap] Rescale category header where needed
Date: Tue, 17 Apr 2012 13:35:22 +0200

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?

> > 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.

> > 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.

> 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.

Ok.

> > 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.

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.

Regards,

Thomas
-- 
Thomas Petazzoni                http://thomas.enix.org
MapOSMatic                      http://www.maposmatic.org
Logiciels Libres à Toulouse     http://www.toulibre.org
Embedded Linux                  http://www.free-electrons.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]