Re: Pictogram specification

On 31/12/12 22:40, Ethan Dicks wrote:
> On Mon, Dec 31, 2012 at 10:08 AM, Markus Dolze<[email protected]>  wrote:
>    
>> Hello LCDproc Developers,
>>
>> during the past months Stefan Herdler, Wolfgang Hauck, and myself discussed
>> how to implement pictograms in LCDproc.
>>      
> Excellent to hear.
>
>    
>> We appreciate any comments from the community.
>>      
> What I see looks good so far.  I don't have any modules with
> pictograms so I can't test it myself but I'm in favor of supporting
> this feature without the "output() hack".
>
> Is there any thought to implementing "virtual pictograms" inside of a
> driver?  It wouldn't affect the pictogram spec as discussed, but one
> could have programmable character pictograms or even ASCII constructs
> that may or may not be implemented by various displays,  As a
> practical example, I'm thinking of "degrees C" and "degrees F" that
> _some_ textual displays have in their ROM-based character sets and
> some do not.  The idea is that a client app could query, say, the
> HD44780 driver and it _might_ know (via .ini file options, perhaps)
> what pictogram name to respond to and what ASCII hex character would
> display that "pictogram".
>
> The most significant difference I can see is that a textual display
> with hardware-implemented pictograms don't have an X-Y coordinate for
> them.  They are on or off wherever the glass has the electrodes.  For
> a "virtual pictogram", if you wanted to place a "degrees F" next to a
> temperature, you'd need a way to tell the driver _where_ to put that.
>
> Is this viable or does this expand the scope too far?
>
> -ethan
> _______________________________________________
> LCDproc mailing list
> [email protected]
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>    

A better way to handle things like the degree sign would be to implement 
UTF-8 support, perhaps in a similar manner to the icon code. So a 
codepoint above U+007F would be passed to the driver which would display 
a character from its ROM or return a not supported code to allow the 
core to provide some basic substitutions such as converting accented 
characters to their unadorned equivalents.

Martin