[minor enhancement] `unlabel` gives `*** NOTE: Non-Hershey fonts: ignoring . . . `

[ryofurue]

I thought it would be nice if this NOTE isn't printed.

When a system font is selected, the go unlabel command gives this warning

*** NOTE: Non-Hershey fonts: ignoring Hershey pen or font codes

(See the self-contained example at the bottom of this message.)

Of course this is harmless; it's just a note. My current problem is that I produce hundreds or thousands of plots using a Ferret script and the screen output, which I look at to monitor the progress of the script, is dominated by this particular message.

A workaround is to filter out this particular message from the output:

pyferret -nodisplay -script myscript.jnl 2>&1 | grep -v 'NOTE: Non-Hershey fonts: ignoring Hershey pen or font codes'

Cheers,

Ryo

!   PyFerret v7.63 (optimized)
!   Darwin 19.6.0 - 10/13/20
! macOS has this font.
set text/font="Lucida Grande"/isiz=3
set data coads_climatology
plot/L=1/y=0/set SST
go unlabel 1; go unlabel 2; go unlabel 3; go unlabel 4
go unlabel 5; go unlabel 6; go unlabel 7; go unlabel 8
ppl plot

[ACManke]

The next release already has a fix for this in an update to the unlabel.jnl script. If you'd like, you can replace the copy of the script with this newer version:

https://github.com/NOAA-PMEL/PyFerret/blob/master/jnls/go/unlabel.jnl

\cancel mode verify ! ... removing the specified PLOT+ movable label
! usage:   GO unlabel label_number
!   where label_number is the label revealed by the command PPL LIST LABELS

!   e.g.  remove the "NOAA/PMEL TMAP" signature label from a plot
!      yes? PLOT/SET_UP/I=1:100 SIN(I/6)
!      yes? PPL LIST LABELS                ! notice #2 is the one to remove
!      yes? GO unlabel 2
!      yes? PPL PLOT

! test argument before performing any actions
QUERY/IGNORE $1"<Usage: GO unlabel n,  where n is a PLOT+ movable label number"

! remove the label by setting its location to the origin with no text content

PPL LABS/NOUSER $1,0,0," "
IF ($program_name"0|Ferret>1|*>0") THEN PPL LABS/NOUSER $1,0,0,@AS

set mode/last verify

In addition, maybe it's time for that warning to go away entirely....

[ryofurue]

IF ($program_name"0|Ferret>1|*>0") THEN PPL LABS/NOUSER $1,0,0,@AS

I see! Thank you for your help! I've downloaded the new version of unlabel

In addition, maybe it's time for that warning to go away entirely....

For that matter, I don't know how to print the "@" symbol on PyFerret when using a system font:

yes? set text/font="Lucida Grande"/isiz=3
yes? set data coads_climatology
yes? shade/L=1 SST
yes? label 180,0,0,0,0.3,"<&copy>" !! -> print the © symbol.
yes? label 180,40,0,0,0.3,"@" !! -> nothing is printed.
           *** NOTE: Non-Hershey fonts: ignoring Hershey pen or font codes
yes?

The at symbol isn't plotted.

The at symbol doesn't have a usual "entity" name. As an "entity", you would write <&#64> using its ASCII code 0x64, but this one completely freezes PyFerret! (I'll write another report if this problem isn't known to you.)

If there is a proper way to print the at symbol, then perhaps you want to disable the warning.

[ACManke]

Yes, please make a new report about the @ symbol. I suspect that this is a bug in the "ignore hershey pen or font codes" logic. By ignoring text that includes @ signs that indicate Hershey fonts, pen colors, and so on. So it's removing the @ sign.

[ACManke]

In fact, you can get the @ sign with this specifier:

yes? label 180,40,0,0,0.3,"<#64>"

In the documentation that's talking about this, https://ferret.pmel.noaa.gov/Ferret/documentation/users-guide/commands-reference/SET#pyferret_embedded_symbols, it says.

The syntax is either <#nnnn> where the number is up to four digits as listed in the HTML character tables, or <&name> if a name is assigned. When the character is a Greek letter, capitalizing the name will result in a capital letter.

So it's not &#64, even though that's what's listed in some of the tables.

The NOTE does need to go away in this instance; for some reason it is issued.

Maybe we could add a note if somebody puts in a specifier using the syntax <&#nnn>. I don't recall what went into this detail, why the specification doesn't use the ampersand.

[ryofurue]

<#64>

Nice! Thanks! But, I guess my comment about it has led this thread to this side track. My bad.