[MPlayer-dev-eng] TODO

[Gábor Lénárt]

On Thu, Jan 10, 2002 at 03:08:16PM +0200, Arpi wrote:
> Hi,
> 
> > > Nice, but imho resizing should be done on font loading time, to avoid
> > > wasted CPU power during each sub drawing process. Also, maybe we can implement
> > > setting font size ON run-time by calling font-set resizer function on resizing
> > > request. The only important opinion from me is to do resizing all signs at
> > > once and not at displaying for each sub/OSD sign.
> > 
> > I want to do it once. it does not make sense
> > to scaling every time we draw a font.
> 
> hey, resizing bitmap fonts is weird idea... it looks terrible :(
> let's generate fonts runtime from .ttf, at given size and codepage and other
> stuff. the font generator code runs <1s on medium systems for ascii set.
> for big unicode sets (korean etc) it may took too long :(

OK, then: let's implement ttf reader in mplayer ;-) Resizing a bitmapped font
can be ugly but resizing a ttf font is not (afaik ttf is described as curves
and so). Or for using the ugly thing (resize bitmapped font) let's resize them
with anti-aliasing not only double some rows/columns to enlarge ;-)
> but we could add font cacheing. for example, user could set a max disk space
> to keep most common font sets...
> 
> the only drawbacks are:
> - runtime generation tooks some time (<1s on most systems and small font
> sizes, but if Michael optimize it it will even build korean 50ppt font at
> 0.1s :)))

:)

> - users need to have freetype library

For XFree4 it's almost standard situation, imho.

> - users need .ttf fonts (they are not fully legal to distribute, at least
> the windows ones, but we could find some free fonts)

OK, then use X fonts ;-) [can be distributed]. Or use installer :) to download
them from m$ (like msttcorefonts debian package does).

- Gabor