On Mon, Dec 31, 2012 at 2:40 PM, Ákos Maróy <[email protected]> wrote:
> On 30/12/12 20:24, Andrea Aime wrote:
>
> O Sun, Dec 30, 2012 at 12:11 PM, Ákos Maróy <[email protected]> wrote:
>
>> PS: all the above assumes that RendererUtilities.getDpi(rendererHints);
>> would return a realistic DPI value when called from StreamingRenderer. I
>> wonder where the DPI value comes from - does for example WMS request supply
>> a realistic DPI value?
>>
> Let's start from this, since this is the underlying assumption that
> unfortunately cannot be met.
>
> thanks for the detailed description provided.
>
> while in the general case the client DPI value might not be known, in the
> cases I'm shooting for, actually I'm able to tell the client DPI. my aim is
> really to show the same (physical) sizes on different density clients,
> therefore a 'pixel' metric is not usable for me. the target devices I'm
> looking at are:
>
> - phones, tablets of different densities, ranging from 72dpi phones to
> retina-display iPhones / iPads
> - physical paper / print (600dpi or 900dpi)
>
> IMHO, the notion of 'pixel' is not particularly useful when it comes to
> styling. it's not even recommended for generic web pages either, where 'em'
> or other non-pixel sizes are generally used when writing 'good' CSS. simply
> one just doesn't know how big a pixel is, and designs based on pixels
> simply don't scale.
>
> and indeed, computer (PC) screens generally know their DPI values as well.
> but in the case of phones, tablets, this is even more true.
>
As I showed in my previous example, while the screen may know its DPI, the
information is often not provided accurately to the OS which is just
making guesses. The same notion is reported by many web sites (that the DPI
reported by the OS is a guess at best).
Also, the dual screen example makes it clear that the notion of a "single"
dpi (right or wrong) is not even applicable.
If we are talking about mobile devices instead then a simple web search
concurs, those generally have an accurate knowledge of their
DPI.
Anyways, let's put that aside and assume that you have some client device
that actually knows its DPI, or you have a user
that can tell you about it.
In this case what you suggested in the first mail, we'd first have to
create a new unit of measure name.
I would avoid creating a new attribute, would just make the coding harder
and besides the current units
contain both real world (metre, foot) and display (pixel).
Given that this is an extension, not something coming from OGC, the URI
representing the dimension on the target device
should also probably be clear about its extension nature... how about:
http://www.opengeospatial.org/se/x-units/target/mm
to specify a size in millimeters on the target device? The "x-units" is
intended to mark the "extension".
Others around here are certainly better than me at picking names, hopefully
they will chime in
(though we might not hear from them for a few days given we're in the
middle of vacations for many).
The DPI would have to be provided using the existing vendor parameter
instead, and we'd default
to roughly 90 as mandated by OGC if not provided.
The idea of using the UomRescaleStyleVisitor is a good one, and would make
for minimal changes.
Whatever patch in this area must be accompained by proper unit testing to
be merged into the code
base.
The patch would land on trunk first, a discussion about a backport on the
stable series can also be
made, the change should not be disruptive.
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
