From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Thu, 11 Feb 2010 09:41:43 -0800

On 11 February 2010 09:02, Alexander Levin <al.le_at_gmx.de> wrote:
> Jonathan Gordon wrote:
>>
>> So here is the question. Is there enough opposition to going about it
>> this way (separate buffers for each font) that someone will put up
>> their hand and do the work so its done properly? Or are we happy to
>> have this "good enough" solution for the time being?
>>
>
> I'm not against separate buffers for each font. But I don't quite like the
> fact that the main and, if present, the remote font are treated in a special
> way (from the skin fonts).
> I would rather see all fonts, except the inbuilt system font, as absolutely
> equal at the firmware level. And I would eliminate static font buffers from
> the firmware and rather allocate them at the app level (where we have much
> more flexibility in where to take it from) and pass it to the firmware
> functions as a parameter.

the sysfont at the very least needs to be handled separately, and the
code to handle the user fonts is only a few extra lines. Moving that
font to the apps/ level will just move the complication which isnt
really needed.

>
> This way we would unify and simplify fonts at the firmware level. Also, we
> would not waste space on targets which can potentially have remotes in the
> case that they are not used.
>
> The buffers for the "main UI" and "remote UI" (if separately specified) can
> be allocated in the skin bufer as well. Why not?
>
See above. We don't really gain anything by moving these.

> As for the browsing "remote fonts": couldn't we do it through the following
> dirty hack: before calling the font browser, save the current "main font"
> setting to a temp variable, then call the browser, then copy the new value
> of the "main font" to the "remote font" setting and then restore the value
> of the "main font" setting.
>
yeah thats not very nice though.
Received on 2010-02-11