Re: Inability to change color of individual substrings

[<pl...@pi...>]

On 30/09/16 07:28, Daniel J Sebald wrote:
> On 09/30/2016 12:24 AM, sfeam wrote:
>> On Thursday, 29 September 2016 10:21:13 PM Daniel J Sebald wrote:
>>> I've noticed that enhanced text mode cannot control the color of a
>>> substring.  Just as a brainstorming exercise, has anyone thought of
>>> adding such a thing in some way?  In principle it's pretty
>>> straightforward: just change terminal color at various points when
>>> processing the string.  But I've a feeling implementation may not be so
>>> easy.  Approaches might be:
>>>
>>> 1) Add some color code extension to the enhanced text processing.  The
>>> code word may not agree with some "standard" described in ps_guide.ps,
>>> but I don't see why that should be a problem.  The problem is that all
>>> terminal drivers would need to be modified to process that code word.
>>>
>>> 2) Create a tex-processing feature, which is similar to enhanced text
>>> (and could use much of the same code), but it would allow using things
>>> like "{\color[rgb]{.3 .7 .3}Hello} World".  Of course, this is no simple
>>> task, but I'm just thinking long term wish if there is no better
>>> approach.
>>>
>>> 3) If there were some way of getting the position at which one
>>> label/string ends, then one could concatenate strings.  I've a feeling
>>> this isn't possible.  I mean, one has to effective do the plot to get
>>> the string-end position, which would be clumsy.
>>>
>>> 4) However, #3 in theory could be implemented as "not lifting pen".
>>> Does gnuplot core code have knowledge of this?  That is, can it do one
>>> label, not lift the pen, then continue with another label?  If so, the
>>> following concept might work:
>>>
>>> set label 1 "{/Times:Bold hello}" textcolor "red" at 1,2
>>> set label 2 "world^3" textcolor "blue" after label 1
>>>
>>> Or, maybe just allow multiple substring specifications, but only a
>>> single "at x,y":
>>>
>>> set label 1 "{/Times:Bold hello}" textcolor "red" "world^3" textcolor
>>> "blue" at 1,2
>>>
>>> Would that work easily internally?  Or is there still a problem as far
>>> as laying out string alignment?
>>>
>>> Dan
>>
>> Always been there:
>>
>> # enhanced text occupy-space-but-don't-print mode
>> #
>> set label 1 at 0,0 "I am a &{red} word in blue"
>> set label 2 at 0,0 "&{I am a} red &{word in blue}"
>> set label 1 tc "blue"
>> set label 2 tc "red"
>>
>>     Ethan
>
> Aaaaah, creative.  The use of &{} is already present in
> enhanced_utf8.dem, but adding a bit of code for this idea to that demo
> might be helpful.  Attached is a diff to illustrate.
>
> I think there may be a bug in Qt terminal with regard to the space
> between &{} and what follows it when there is a space-character
> immediately after.  I tried explicitly using a \040, but that too was
> dropped.  After applying the attached patch, try
>
> set term x11 enhanced
> load 'enhanced_utf8.dem'
>
> and
>
> set term qt enhanced
> load 'enhanced_utf8.dem'
>
> The only way I could get the proper spacing with the Qt terminal is by
> adding '|', e.g., "&{{/:Bold Bold} and|} {/:Italic Italic}"
>
> Dan
>
>

I was not aware of this &{} syntax.  Looks very useful.

Where can I find the relevant documentation? What is this feature 
called, for example, in help?

TIA. Peter.