Hi Vincent,
Having got my <rant /> off my chest, I won't argue with you - it is,
as you say, a little off-topic. My gripe is with the definition, not
the implementation!
best wishes,
Martin
On 24 Apr 2009, at 11:54, Vincent Hennebert wrote:
Hi Martin,
Unless I misunderstood you, this is a different topic. If all the
dimensions in the file are given using absolute units (pt, mm, in,
etc.), then the file is indeed independent of any resolution. It is up
to the output device to convert those measures into the right amount
of
pixels, knowing its own resolution. A screen whose resolution is 72dpi
will render a one inch long line on 72 pixels. A screen at 96dpi on 96
pixels. A printer at 600dpi on 600 pixels, etc.
Now, it is true that in the SVG format there is the ‘px’ unit [1] for
which a correspondence must be given. To keep it short, the user has
to
define to how many points (or cm, or in) 1 px must be mapped. In FOP
this is done using the ‘source-resolution’ parameter [2]: it tells how
many of those ‘px’ can be found in one inch (72, by default).
If in your SVG file you set the text size to 24pt and your system is
properly set up, then when you display the file on the screen at a
zoom
of 100% you will actually see that the text is 24pt high.
[1] http://www.w3.org/TR/SVG11/coords.html#Units
[2] http://xmlgraphics.apache.org/fop/0.95/configuration.html
Vincent
Martin Jacobson wrote:
Hi,
<rant>
There seems to be a misconception frequently found in the SVG/PDF
community that because vector graphics can be scaled with no change
in
image quality, they are somehow 'independent' of notions of
resolution.
Unfortunately, this isn't correct. Any piece of vector image must be
drawn at the same scale as all the others in order to have the
correct
relative size in the final image. So we have to know what that
scale is.
It would be nice to be able to set that scale so it matched the
resolution of the output device because then we could place text at a
given (absolute) size, such as 24pt knowing that changing the scale
would not change the relative size of the text, but alas! this is not
the case; someone decided that The Scale shall be 1:72, which means
that
text has to be manually scaled according to the output resolution.
</rant>
I feel better for that
Martin
On 24 Apr 2009, at 10:32, Vincent Hennebert wrote:
Hi,
Like you noticed the resolution only applies to images. I am
slightly
puzzled by the way you compare both outputs: are you putting the
sheet
of paper next to the screen and looking for differences?
Then note that the HTML result is likely to be highly different
from one
environment to the other (think of a desktop machine compared to
a smartphone), and it is dependent on many settings: the
resolution of
the screen, the default font and font sizes chosen by the user, the
default stylesheet they may want to apply, etc.
Also, PDF is a vectorial format, so the notion of resolution doesn’t
apply to it (except the raster images that it may contain).
So yes, in the end what you want to do is to play with font sizes,
rather on the FO output. For the HTML output better leave them to
their
default values, and let the users choose the default sizes that suit
them.
kkapelon freemail gr wrote:
Hello list!
I have an XML file which is either converted to PDF (via FOP) or to
XHTML (via another XSL stylesheet)
I have noticed however that things look different in (printed) PDF
and (on-screen) HTML formats.
The sizes are different for the text elements.
After searching for a cause it came to my attention that PDF files
from FOP
are rendered at 72DPI (correct me if I am wrong) while the
browser/screen/OS works at 96DPI.
I found the configuration for dpi at
http://xmlgraphics.apache.org/fop/0.95/configuration.html, but this
applies only to images and not text.
So is there a workaround to make things appear on print the same as
they are on screen?
I am thinking of manully changing the sizes in one stylesheet
(either
for FO or HTML) to bring it
to the same "size" with the other. But I wonder if there is a more
elegant solution.
Thank you
Hope this clarifies the thing a bit.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Sent from my Mac
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: fop-users-
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Sent from my Mac
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
