Re: Pictogram specification

On Tue, Jan 1, 2013 at 9:52 AM, David Glaude <[email protected]> wrote:
> Le 31 déc. 2012 23:40, "Ethan Dicks" <[email protected]> a écrit :
>> Is there any thought to implementing "virtual pictograms" inside of a
>> driver?
>
> I think that what you are really asking for is an extension of the current
> icon set to include 'C°' and 'F°' . It might be replaced by 'C' and 'F' for
> lcd without custom character.
>
> Would that fit your needs?

Perhaps.  I just remember running into issues with writing weather clients
that had to be told at run-time what character set the display had to know
how to handle a degree "glyph" because I was using three LCD modules
for test (one VFD, two LCD, actually) and there was little common ground
outside of 7-bit printable ASCII.  This could easily be a different problem
to solve without pictograms, but I was reaching for an example to
illustrate my idea and I didn't reach far enough.

> What I can imagine is a 20x2 LCD that is advertised (by the driver) as a
> 16x2 where 4x2 would be used to create simulated pictogram.

This is more like what I was thinking of but you've come up with a better
way of visualizing it.  I'd even be happy with a 2x2 simulated pictogram
on a 16x2.

One display I have in particular is a 640x40 pixel t6963 from a 1995
Toshiba multimedia peripheral that snapped into a docking bay in the
main system's CRT.  Treating it as a textual display under LCDproc
(with glcdlib at the time), there's room for 80x5 characters (with 8x8
pixel characters) or, something I've always thought with a display of
this geometry, to reserve a 40x40 patch off the right edge, leaving
plenty of room for even 40x5 characters, and then the 40x40 block
at the edge could be used for pictograms (my initial thought was
weather forecast symbols).  Of course the driver would implement
the details as long as there was an API for clients to use.

I should probably mention that unlike an LCD or VFD with "real"
pictograms, this virtual pictogram on a graphical display could
be implemented not as a set of non-overlapping images but a
single "canvas" that would display the most recently invoked
pictogram, but it could also be used for displaying a range of
values like a WiFi signal strength icon or a "successive pie wedge"
circular timer image.

But I do agree that the details could be/should be embedded in
the driver and could be turned on or off from an .ini file option
and could aid client debugging and development to have an LCD
with virtual pictograms instead of having to track down each kind
of custom LCD or VFD.

-ethan