8:35 p.m.
Hi,
I am greatly disappointed with this week's work of mine. Although I finished
my idea of the fuzzy margins with visible effects ( you look how
http://www.netsurf-browser.org/documentation/guide is printed - a lot of text
breakings are fixed), I wasted a lot of time with figuring out the maths and
geometry (PDF files have the y-coordinate rising upwards and the (0,0) point
in the bottom-left corner of the page) - I made a lot of stupid errors while
coding it the first time. I'm in doubt, whether to use this method for the
top of pages too. The top of the page is the one more visible and the fuzzy
margins will probably make a more visible difference.
I moved also some responsibility for margins etc. to the plotter code, to make
printing less dependant on the way margins and page sizes are set.
For this week I plan to change the layouting for printed content, so that all
of it will be fit in the available width (the 'loose' layout that I wrote
about last week).
Adam
2:27 p.m.
In message <200806212035.11831.adamblokus(a)gmail.com>
Adam Blokus <adamblokus(a)gmail.com> wrote:
Hi,
I am greatly disappointed with this week's work of mine.
He, don't be too hard for yourself ;-)
Although I finished
my idea of the fuzzy margins with visible effects ( you look how
http://www.netsurf-browser.org/documentation/guide is printed - a lot of text
breakings are fixed), I wasted a lot of time with figuring out the maths and
geometry (PDF files have the y-coordinate rising upwards and the (0,0) point
in the bottom-left corner of the page) - I made a lot of stupid errors while
coding it the first time. I'm in doubt, whether to use this method for the
top of pages too. The top of the page is the one more visible and the fuzzy
margins will probably make a more visible difference.
I'm probably too late with this idea but if the difference of coordinate
system is bothering you too much, why not make it the same by calling
HPDF_Page_Concat (you already do this for accounting the left margin) ?
I moved also some responsibility for margins etc. to the plotter
code, to make
printing less dependant on the way margins and page sizes are set.
For this week I plan to change the layouting for printed content, so that all
of it will be fit in the available width (the 'loose' layout that I wrote
about last week).
This is including teaching NetSurf layout code to take the text width
determined by the backend into account (as the fonts used in PDF output
do not necessarily have the same width as what the layout engine was
using) ?
John.
--
John Tytgat
joty(a)netsurf-browser.org
5:17 p.m.
I'm probably too late with this idea but if the difference of
coordinate
system is bothering you too much, why not make it the same by calling
HPDF_Page_Concat (you already do this for accounting the left margin) ?
Actually, I tried to use it at the very beginning. But this transformation
influences not only the positions of the elements, but also fonts and bitmaps
are shown upside-down.
The problem with coordinates was completely my fault and it took me way to
long to figure it out - but all is solved right now, should not happen
anymore ;)
> I moved also some responsibility for margins etc. to the plotter
code, to
> make printing less dependant on the way margins and page sizes are set.
>
> For this week I plan to change the layouting for printed content, so that
> all of it will be fit in the available width (the 'loose' layout that I
> wrote about last week).
This is including teaching NetSurf layout code to take the text width
determined by the backend into account (as the fonts used in PDF output
do not necessarily have the same width as what the layout engine was
using) ?
I am not sure if after adding the possibility to embed fonts this couldn't be
done by the same nsfont_width function, that determines text width for the
window. If not - I will most surely parametrize the function being used for
it.
Adam
5:38 p.m.
In message <200806221717.47482.adamblokus(a)gmail.com>
Adam Blokus <adamblokus(a)gmail.com> wrote:
> > I moved also some responsibility for margins etc. to the
plotter code, to
> > make printing less dependant on the way margins and page sizes are set.
> >
> > For this week I plan to change the layouting for printed content, so that
> > all of it will be fit in the available width (the 'loose' layout that
I
> > wrote about last week).
>
> This is including teaching NetSurf layout code to take the text width
> determined by the backend into account (as the fonts used in PDF output
> do not necessarily have the same width as what the layout engine was
> using) ?
I am not sure if after adding the possibility to embed fonts this couldn't be
done by the same nsfont_width function, that determines text width for the
window. If not - I will most surely parametrize the function being used for
it.
If you manage to always embed the fonts in the PDF output then yes,
nsfont_width can remain the same as it is. However, at least for RISC OS
version of NetSurf this won't be the case as there RISC OS fonts are used
and libharu does not have code to convert those to one of the font types
supported by PDF. So we'll need to do something with nsfont_width to
look after this usecase.
John.
--
John Tytgat
joty(a)netsurf-browser.org
5645
days inactive
5646
days old
netsurf-dev@netsurf-browser.org
3 comments
2 participants
participants (2)
-
Adam Blokus -
John Tytgat