xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergiu Dumitriu <sergiu.dumit...@gmail.com>
Subject Re: SVG pixel size
Date Tue, 09 Jul 2013 18:44:12 GMT
On 07/09/2013 01:43 PM, Vincent Hennebert wrote:
> On 09/07/13 18:51, Sergiu Dumitriu wrote:
>> On 07/09/2013 12:26 PM, Vincent Hennebert wrote:
>>> Hi Massimo,
>>>
>>> the easiest is to have the source resolution match the target
>>> resolution. That way, one pixel in your source will become 1 pixel in
>>> the output.
>>>
>>> That said, if you want a real one-pixel line and not something
>>> anti-aliased you have to ensure that the coordinates will match output
>>> pixels. Start by setting the font-size on the outer block to 0, in order
>>> to avoid that the baseline ends up somewhere in between two pixels.
>>> Then, for some reason, you have to set the y pixels to half values. For
>>> example, 1.5px. I haven’t investigated why.
>>
>> Because the stroked line width is split evenly around the imaginary line
>> defined by the coordinates. If it goes through 1.5, then 0.5px will be
>> above and 0.5px will be below it, which means that it actually fills in
>> a solid stripe between 1.0 and 2.0, which is exactly a pixel without any
>> antialiassing.
> 
> I was looking in the SVG Recommendation for something similar to the
> description in the javadoc of Graphics2D:
> http://docs.oracle.com/javase/1.5.0/docs/api/java/awt/Graphics2D.html
>   “The JDK(tm) 1.1 rendering model is based on a pixelization model that
>   specifies that coordinates are infinitely thin, lying between the
>   pixels. Drawing operations are performed using a one-pixel wide pen
>   that fills the pixel below and to the right of the anchor point on the
>   path.”
> 
> I couldn’t find anything though. Do you happen to have any pointers?

Couldn't find anything after a quick scan of the specification, but it
makes sense since SVG is "scalable". Unlike Java graphics, which is
clearly targeting interactive displays (screens), and most coordinates
are integers, SVG is defined as scalable, device- and
resolution-independent graphics. It works on an abstract mathematical
canvas, and coordinates are abstract points, with zero width, around
which paint is applied with a real width.

The pixel (px) doesn't make that much sense defined as a screen dot,
since one of the main targets of SVG is print, and a possible usecase is
for SVG to be implemented as a standard printer language, alongside PCL
and EPS, and printers don't have pixels (that's the purpose of SVG Print).

Another aspect is that units correspond to pixels only in the initial
coordinate system, but that one isn't fixed. The actual coordinate
system can be either explicitly or automatically changed, so in the end
a pixel length can be equal to 10 device pixels, or 0.024 device pixels.
Should everything be shifted by 0.5 device pixels so that they align nicely?

> According to that model, there would be no need to specify coordinates
> in 0.5 to have full lines.
> 
> SVG seems to do the same as PDF however:
>   “stroking a path entails painting all points whose perpendicular
>   distance from the path in user space is less than or equal to half the
>   line width.”
> 
> That makes sense I guess.
> 
> 
>> If it were to pass through 2.0, then it would end up as a solid stripe
>> between 1.5 and 2.5, which means that half of the first pixel and half
>> of the second pixel must be stroked, and since half pixels can't be
>> drawn, antialiassing is used.
>>
>> I usually shift the viewbox by 0.5px to get rid of this problem and use
>> integer coordinates in the rest of the SVG.
> 
> 
> Thanks,
> Vincent
> 
> ---------------------------------------------------------------------


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message