When setting up global macro variables for symbols:
%let sle =~{unicode 2264};
%let sge =~{unicode 2265};
I do this also:
%let sle = &sle;
%let sge = &sge;
But when I write a footnote such as the following:
footnote6 height = 5pt j = l "Response = CFB&sge.7 units";
There is an extra space between the word "Baseline" and the symbol. The destination is ODS PDF.
I received a reply from SAS on this issue:
This is regarding SAS Technical Support Case CS0103716: [Extra space when resolving "macrotized" Unicode symbols in footnotes using Pearl Style in ODS PDF].
This is a known issue. However, to see if this circumvents the issue (or at least minimizes the issue), add the following option to the end of your current ODS PDF FILE= statement:
DPI=600
I doubt if the macro variable has anything to do with what you are seeing. Once the macro variable is resolved you have run this statement:
footnote6 height = 5pt j = l "Response = CFB~{unicode 2265}7 units";
So it sounds like your issue is with how ODS PDF inserts the unicode character.
It also is going to matter what FONT you are using.
As long as I don't use unicode symbols and just type ">=" no extra space.
The font is default for PDF (Sans Serif perhaps)?
@_Hopper wrote:
When setting up global macro variables for symbols:
%let sle =~{unicode 2264};
%let sge =~{unicode 2265};
I do this also:
%let sle = &sle;
%let sge = &sge;
But when I write a footnote such as the following:
footnote6 height = 5pt j = l "Response = CFB&sge.7 units";
There is an extra space between the word "Baseline" and the symbol. The destination is ODS PDF.
What is providing the word "Baseline" in the output? With what you show above there would have to be a few more steps for "Baseline" to appear. Perhaps you need to edit the post to be consistent? Or the code that is adding "Baseline" is the issue.
B = Baseline
I originally chose to abbreviate the words then wrote them out. This has no impact on what the output is doing.
@_Hopper wrote:
B = Baseline
I originally chose to abbreviate the words then wrote them out. This has no impact on what the output is doing.
But does go to clarity of understanding the problem. So instead of "Baseline" it would have been clearer to say "CFB" and I would not have been confused. 🤔
Hi:
I do not observe a space when I do a simple test. I chose a larger font so I could see the spacing better. I used both the TITLE and FOOTNOTE statements as shown below:
Maybe this is something you might want to work on with Tech Support because then they could look at ALL of your code and make suggestions.
Cynthia
Thanks Cynthia - I've not seen this type of behavior before with symbols.
I started a case with SAS TS.
Cynthia's output does show the normal disconnect when embedded non-standard characters into a line of text. The baseline for the less-than-or-equal symbol seems different than for the normal letters. Perhaps caused by using glyphs from different fonts. But it does not show a space.
Are you sure you did not accidentally embed a non-breaking space (or other invisible character) into your macro variable? Try examining the value of your macro variable use $HEX format.
data _null_;
sle = "&sle";
put sle $hex. ;
run;
Try running both ways to add the unicode call code into your footnote into the same report and see if you still see a difference.
footnote1 "baseline&sle.XXX";
footnote2 "baseline~{unicode 2265}XXX";
And if there is no hidden character in your macro variable but using the macro variable versus hard coding the unicode call text does produce different output (sometime the SAS parser gets confused when seeing macro expressions) then generate the full text into one macro variable and use that in the code.
%let footnote=baseline&sle.XXX;
footnote1 "&footnote";
I received a reply from SAS on this issue:
This is regarding SAS Technical Support Case CS0103716: [Extra space when resolving "macrotized" Unicode symbols in footnotes using Pearl Style in ODS PDF].
This is a known issue. However, to see if this circumvents the issue (or at least minimizes the issue), add the following option to the end of your current ODS PDF FILE= statement:
DPI=600
I'm confused. When TS says it's a known issue, did they define the issue? It has nothing to do with the macro language, right?
If you hard code it like in Tom's post, you get the same problem right?
footnote6 height = 5pt j = l "Response = CFB~{unicode 2265}7 units";
If this is somehow related the macro language that would be very surprising.
@Quentin wrote:
I'm confused. When TS says it's a known issue, did they define the issue? It has nothing to do with the macro language, right?
If you hard code it like in Tom's post, you get the same problem right?
footnote6 height = 5pt j = l "Response = CFB~{unicode 2265}7 units";
If this is somehow related the macro language that would be very surprising.
Since the note from Tech support specifically states the ODS style Pearl that sounds like an option used in the style definitions are interacting. Since Pearl is, as I understand it, intended for use with PowerPoint then there may well be interesting stuff in the style to deal with the options in PowerPoint especially related to slide title text. What is of interest is has the OP included use of Pearl as the ods style in effect? Or PowerPoint as a destination?
Actually that was the ticket that mentioned Pearl, not the tech support note.
I found the ts note: https://support.sas.com/kb/56/784.html
It seems related to use of a sans-serif font. Looks like it's fixed in M7 on most platforms. Happy to see the ts note confirms the problem to does not relate to use of a macro variable.
Registration is now open for SAS Innovate 2025 , our biggest and most exciting global event of the year! Join us in Orlando, FL, May 6-9.
Sign up by Dec. 31 to get the 2024 rate of just $495.
Register now!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.