Re: Pictogram specification

Hello!

Am 31.12.2012 23: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".
The current discussion is only about pictogramms outside the text-area 
of the display.

The main intention is to get rid of the "output()" hack and make these 
pictogramms accessible to the clients.
This should be done in a universal and adaptable way for all Displays 
and without the need of hardware programming knowledge at the client.

Controlling this pictogramms is planned to be independent of the shown 
screen to allow background-processes setting their pictogramms without 
interrupting the text-output.

The pictogramms are intended as extra-features of the display a 
fall-back-functionality in the core is not planned.
A driver of a big graphics-display might implement pictogramms in a 
reserved space, but that's a special case.
>
> 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".
Pictogramms are by definition always outside the text-area of the display.

You're talking about icons and custom-characters.
And yes, there were some thoughts about that, at least by me.

Making custom-caracters accessible to the client is fare more 
complicated compared to the pictogramms.
Currently the LCDd uses these custom-characters for his own purposes 
like Bars or Icons...
There have to made some fare-reacting changes to the core to make it work.
It is a complete different subject.

This also applies to the utf8 whatever characterset conversion which has 
to be solved sometime.


regards
Stefan

>
> 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
>