> I've commited the patch. It's much larger than I thought. diffstat
> says, "31 files changed, 801 insertions(+), 838 deletions(-)." :-)
Thanks! It looks fine. Will test soon.
> I'll add back the selection of size through real dimensions for
> bdf/pcf fonts and mention the changes in the do
Hi all,
I've commited the patch. It's much larger than I thought. diffstat
says, "31 files changed, 801 insertions(+), 838 deletions(-)." :-)
The patch became so large partly becaue I moved "sbit metrics loading"
code to the sfnt module, which is now shared by cff and truetype
modules. This ch
> Since FT_Set_Pixel_Sizes might set the nominal size or the real
> dimension in a unpredictable way, this is the first thing to fix. I
> chose to make it always set the nominal size.
OK.
> Further, I added `select_size' to the driver interface, which selects a
> fixed size by its index in avai
On Fri, Dec 09, 2005 at 09:30:27AM +0800, Chia-I Wu wrote:
> To remedy this, the definition of FT_Set_Pixel_Sizes is changed to set
> the real height, not the nominal height. BDF/PCF drivers are also
> updated to reflect this change.
>
> As you can see, the problem is that other drivers are not u
Hi,
I guess I better describe the problem more thoroughly. Let's begin with
a review of the current status of FT_Set_Pixel_Sizes.
FT_Set_{Char,Pixel}_Sizes, at the first place, is used to set the size
of the em square (nominal size). It works well with all scalable fonts.
And in theory, it shou
On Wed, Dec 07, 2005 at 03:26:12PM +0100, Werner LEMBERG wrote:
> > > How do you come to this conclusion? The original BDF
> > > specification (found in the X11 distribution) says that both
> > > FONT_ASCENT and FONT_DESCENT are *logical* values. They don't
> > > guarantee that all bitmap glyphs
> > How do you come to this conclusion? The original BDF
> > specification (found in the X11 distribution) says that both
> > FONT_ASCENT and FONT_DESCENT are *logical* values. They don't
> > guarantee that all bitmap glyphs are within this range.
>
> Still, then we should set y_scale to 8 / (fac
Hi,
> The question isn't stupid at all. The difference comes from the TrueType
> bytecode specification, which makes a specific distinction between these
> two scaling modes.
> I can't remember the details though...
Hmm... the truetype driver doesn't seem to distinguish them. Is it
unimplemented
Hello,
>
> > I also have a (maybe stupid) question. Why don't we simply have
> >
> > FT_Set_Pixel_Sizes( face, w, h )
> > {
> > FT_Set_Char_Size( face, w, h, 72, 72 ):
> > }
> >
> > ?
> (More looking forward to comments on this question actually)
>
The question isn't stupid at all. The diffe
On Tue, Dec 06, 2005 at 11:53:01AM +0100, Werner LEMBERG wrote:
> How do you come to this conclusion? The original BDF specification
> (found in the X11 distribution) says that both FONT_ASCENT and
> FONT_DESCENT are *logical* values. They don't guarantee that all
> bitmap glyphs are within this
>
> This means that setting the pixel size to, say, 8x8 doesn't
> guarantee in any way that you get glyph bitmaps that all fit within
> an 8x8 cell (sometimes even far from it).
>
> ...
>
> For BDF and PCF formats, this function uses the sum of the
> `FONT_ASCENT' and `FONT_DESCENT' properties o
On Sat, Dec 03, 2005 at 04:15:09PM +0800, Chia-I Wu wrote:
> I find these two paragraphs conflicting. If we use the sum of
> FONT_ASCENT and FONT_DESCENT to match against, then all glyphs are
> within the 8x8 cell, provided FT_Set_Pixel_Size( face, 8, 8 ) returns
> success. Or put it in another w
Hi,
According to the document,
This means that setting the pixel size to, say, 8x8 doesn't guarantee in
any way that you get glyph bitmaps that all fit within an 8x8 cell
(sometimes even far from it).
...
For BDF and PCF formats, this function uses the sum of the `FONT_ASCENT'
and `FONT_DESCEN
13 matches
Mail list logo
