Improper alignment and Height issue with inline formatting - sas

ods escapechar='^';
%let bmi=^S={font_weight=bold} Body Mass Index(Kg/m^{super 2});
When i am trying to create pdf o/p my font is changing in output(Superscript appears in different height)
Is there any solution for the above issue

I think the problem is that you are overriding the style inline, which SAS handles a bit oddly. I am assuming this is a TITLE element below, but the same rules apply no matter where it's coming from.
<td class="c systemtitle">
<span class="c" style=" font-weight: bold;">
Body Mass Index(Kg/m<sup>2</sup>)
</span>
</td>
Notice the class of the span: it's not a systemtitle anymore, it's just a 'c' (which is generic centered text). More than likely your style doesn't properly implement superscripts in generic centered text. I would look at that and see if changing styles works. In general, it is better to do things like the font-weight:bold in styles rather than in inline formatting; you might find you have better luck with that.
I would also add that in the default style in 9.3 for PDF, this isn't a problem, using the default PDF driver in base SAS. If you're running this in EG, it uses a slightly different driver to print PDFs, so that could also be worth trying; options dev=PDF; fixes it.

Related

MudBlazor: font-size and spacing in MudSelect and MudList

For my purposes, the font size and spacing of the individual items in MudSelect and MudList don't work for me. Unfortunately, my attempts to change these parameters with styles were unsuccessful. That is, the components don't respond to the "font-size:" setting in the style.
<MudListItem Style="font-size: 10px">#context.Name</MudListItem>
How can I do this?
Try this:
<MudListItem Style="--mud-typography-body1-size: 10px;">#context.Name</MudListItem>
https://try.mudblazor.com/snippet/cOwQOZnYeaGHumVm

papaja: Changing font sizes and faces for code listings and R output

Based on the answer to this question, I was able to get 2-column papaja with listings wrapping (rather than overflowing column width). But the listings package turns off various features that help code listings and R output stand out relative to the main text.
A simple solution would be if I could globally change the font faces and/or sizes selectively for code and R output. Is there a way to do that in papaja? I haven't been able to figure this out from papaja or Rmarkdown documentation. Thank you!
When you use the listings package in a papaja (or bookdown) document, what is technically happening is that all code is wrapped into an lstlisting LaTeX environment that comes with its own capabilities of customizing code appearance. Hence, you don't see the syntax highlighting that you would otherwise see if you would not use the listings package. The documentation of the listings package with instructions how to style your code can be found here.
To make use of this, you can extend the YAML header of your papaja document like this:
documentclass : "apa6"
classoption : "jou"
output :
papaja::apa6_pdf:
pandoc_args: --listings
header-includes:
- \lstset{breaklines=true,language=R,basicstyle=\tiny\ttfamily,frame=trB,commentstyle=\color{darkgray}\textit}
Here, I first specify the code's language, and use a tiny monospace font. With frame, I add a frame around the code block, and with commentstyle I set comments in italic and gray.

How to do RTL with django-easy-pdf

I'm using django-easy-pdf in a project to provide an output report. Works great. I'm just adding Hebrew to the languages available and I cannot get the output in RTL.
I've tried a number of approaches to force RTL formatting including hard-coding
html, body, p, table, tr, td, span {
direction: rtl;
}
within the tags in base.html.
Does django-easy-pdf support RTL and if so, how do I implement it?
solution: use django-weasyprint instead

Better legibility of Thymeleaf template

I created a lot of Thymeleaf templates during the last weeks, using both html5 and textual mode. In these templates I need to use a lot of th:each statements that iterate over the Context variables.
On these variables I ofter access their getters which in turn return other objects which I have to use getters on and so on.
In order to process the data returned I need to apply stuff like strings.defaultString(...)
All these combined statements make it difficult to read and comprehend what is going on. Many lines of my templates are so long that they can't be read without scrolling horizontally.
I searched for best practices but only found some that describe how to create "base templates" that give general advice on using Thymeleaf in combination with Spring or mention how to include common fragements.
Is there best practice how to format / wrap Thymeleaf statements without causing negative effects on created html or text (for example unwanted line breaks) ?
You can create variables using th:with so that you dont have to do frequent objA.propB.propC. So you assign th:with="propB=${objA.propB}"
Then creating reusable fragments with parameters in another good approach so any HTML which is getting repeated can be extracted into a fragment and the data required for that fragment can be passed as argument.
Update:
<div class="profile-user-info">
<th:block th:insert='~{::profileInfoRow("Name", ${user.name}) }' />
<th:block th:insert='~{::profileInfoRow("Age", ${user.age}) }' />
<th:block th:insert='~{::profileInfoRow("Location", ${user.location}) }' />
</div>
<div th:fragment="profileInfoRow(label, value)">
<div class="profile-info-row">
<div class="profile-info-name">[[${label}]]</div>
<div class="profile-info-value">[[${value}]]</div>
</div>
</div>
So above is a simple way you can create a reusable section of HTML and then use thymeleaf directives to include the reusable section by passing in the values for dynamic arguments.

New Symbolic Color in Pango Span Text

First time poster; long time admirer of the Stack Overflow angels.
I'm having an issue with colors in span text that are controlled by Pango.
Long Version:
I'm updating an old UI program which has C++ code guts with GTK, XML (written by Glade), and an RC stylesheet handling the graphics. Some of our colored markup text is hard-coded in the XML. Some of it is dynamically set in the C++ code.
The problem is, that when the program runs on our older systems, the color referenced by span text as 'green' shows up as #00FF00. On our newer systems, 'green' is showing up as #008000.
Example of code printing to a label widget:
gtk_label_set_markup((GtkLabel *) TitleBarLabel, "<span color='green'>Orbital Cannon Positioning</span>");
I'm fairly certain that Pango is in control of the span text markup. I found that the difference between the greens is exactly the difference between X11 and W3C color lists (https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors).
It seems that our old systems are using X11 and our new ones are using W3C, which makes sense.
I could just replace all instances of 'green' with '#00FF00' but if we wanted to change the colors in the future, we'd have to go through the whole thing again. I'd much rather have the colors changeable through a stylesheet instead of baked into the code.
C++ Code:
GtkWidget * TitleBarLabel;
TitleBarLabel = GTK_WIDGET (get_builder_object (builder, "TitleBarLabel"));
gtk_label_set_markup((GtkLabel *) TitleBarLabel, "<span color='#00FF00'>Death Ray Power Status</span>");
I can create a GdkColor at run-time and gdk_color_parse it with values from a config file, and then use gtk_widget_modify_text() to apply the color to the label widgets. But then that doesn't work for all of the hard-coded span text in the XML. Also, we have pleanty of labels with bits of text colored differently inside the same line.
C++ Code:
GdkColor pass_color;
gdk_color_parse("#00FF00", &pass_color);
gtk_widget_modify_text(TitleBarLabel, GTK_STATE_NORMAL, &pass_color);
I can make a style in my RC file for each color and link every single label that would use that color at run-time. But we'd have to remove all markup coloring and add lots of code for grabbing widgets that we never bothered with before and code for setting names of widgets instead of just printing to them with new span text. It gets the desired result of having the colors changeable in a stylesheet but it's a massive undertaking and it's not intuitive for our veteran engineers who are used to using the color attributes.
RC File:
style "pass_color"
{
fg[NORMAL] = #00FF00
}
widget "*TitleBarLabel_Pass" style "pass_color"
C++ Code:
gtk_widget_set_name(TitleBarLabel, "TitleBarLabel_Pass");
Short Version:
Ideally, I would like to be able to make a new color at run-time that we can link with span text in such faction:
<span color='MyNewColor'>Weather Manipulation Settings</span>
Or maybe even create a new tag that applies specific attributes, like:
<span><MyNewColor>Shark Tank pH Balance</MyNewColor></span>
But I doubt that's possible.
I tried playing around with pango_attr_type_register(), pango_attr_foreground_new(), and friends, but I couldn't figure out how attributes work of if they could even do what I thought they did. After much research, it looks like an 'attribute' is just a one-time setting on a single string of text. And not a new value that can be called in line with span text, as I hoped.
Is anything like this remotely possible without rebuilding all of Pango?
Is there a different work around that would get me a stylesheet like setup?
At this point, I'm open to suggestions.
Version Specs:
Computers showing green as #00FF00
OS: Linux Slackware 13.37 and below
GTK: 2.24.4
Pango: 1.28.4
Computers showing green as #008000
OS: Linux Slackware 14.1
GTK: 2.24.20
Pango: 1.34.1
If you are able to use GTK 3.x, I would suggest doing that, where this is much easier to do using CSS. There is even a way to use multiple CSS styles for different regions in the same label, though it is awkward.
In GTK 2, as you noted, you can reference widgets by their name property in your RC file:
widget "shark-tank-ph-label" style "green-text"
style "green-text" {
text[NORMAL] = #008000
}
I would recommend taking this approach even if it's not what you're used to. Refactoring once to remove the hardcoded colors from your labels will make it much easier the next time you have to change something like this, and will also make your code closer to how things would work in GTK 3.x should you decide to make a port in the future.