It has been possible to configure OpenType variations in "editor.fontLigatures" for a long time by now, but it's very limited. E.g., to configure the double-storey 'g' for the Iosevka font, one can add this to settings.json:
"editor.fontLigatures": "'cv32'"
This sets the cv32 parameter to 1. However, as far as I know it's not possible to specify the value, e.g. cv32=2 to get the double-storey-open variant.
In 1.74 they added "editor.fontVariations", and promised that it would do the job like this:
"editor.fontVariations": "'ital' 0.5"
(See https://code.visualstudio.com/updates/v1_74)
This does not seem to work. No OpenType parameters work here, there is no effect on font rendering. They do work in the old, limited way in fontLigatures.
What am I doing wrong? How are these two configuration parameters expected to work? Is it working for anyone, possibly with a different programming font?
There is info in OTVAR fonts: fontWeight/wght conversion fails on how this setting works.
If fontVariations is true, we translate fontWeight to
"font-variation-settings: 'wght' ${value}". We don't set font-weight
CSS property because they seems conflicting with each other.
The reason why we do like this is that font weight is a register
variable axis. So if people are using a variable font (e.g. Cascade
Code, Berkeley Mono) and they don't care about other variable axes,
they can simply set this property to true to enable variable weights.
If fontVariations is false, we translate fontWeigh to "font-weight:
${value}". This is identical to current behavior.
If fontVariations is a string, we pass it as the value of
font-variation-settings CSS property. In this case, font-weight is
ignored.
But near the end of that issue it is noted that the Chromium engine that vscode uses isn't rendering this correctly on Windows if I read that issue correctly.
These settings depend on fonts that support the capabilities they activate. From the VS Code doc'n:
// Configures font ligatures or font features. Can be either a boolean to enable/disable ligatures or a string for the value of the CSS 'font-feature-settings' property.
"editor.fontLigatures": false,
If set to true, that will activate OpenType ligature features, if they are supported in the font. But if set to some other string like "'cv32'", that will activate that specific OpenType feature — the 'cv32' feature — if that is supported in the font.
Here's the description for the 'cv01' – 'cv99' features: https://learn.microsoft.com/en-us/typography/opentype/spec/features_ae#cv01-cv99
OpenType has different ligature features. The 'liga' (standard ligatures feature should normally be activated by default, though I don't know what Electron / VS Code does if .fontLigatures is false. Here are other ligature-related features:
'clig' (contextual ligatures)
'dlig' (discretionary ligatures)
'hlig' (historical ligatures)
'rlig' (required ligatures)
The 'clig' and 'dlig' features certainly ought to be activated or deactivated using boolean values for .fontLigatures. It probably would make sense to .fontLigatures to do the same for 'hlig'. But 'rlig' shouldn't be affected by .fontLigatures since the intent of the feature is for ligatures that are required for correct display of a script, such as the lam-alef ligature in Arabic.
Now let's look at what the VS Code documentation says regarding .fontVariations:
// Configures font variations. Can be either a boolean to enable/disable the translation from font-weight to font-variation-settings or a string for the value of the CSS 'font-variation-settings' property.
"editor.fontVariations": false,
The first part is not entirely clear, but I gather that a boolean value of true will cause a font-weight: nnn CSS property to be changed to the property font-variation-settings: "wght" nnn, which is functionally almost the same. (CSS cascading works differently, but otherwise they would do the same.)
But let's step back for a moment to explain what the font-variation-settings property does: it's intended specifically for use with OpenType variable fonts. A variable font has one or more axes of design variation, typically with continuous variation on each axis. Within the font, all variation axes are designated with a four-character tag, such as "wght" or "wdth". Many variable fonts support a weight axis (the tag for which is "wght"), but it's entirely up to a font designer what the axes of variation are. See https://v-fonts.com/ or https://www.axis-praxis.org/ for many examples of variable fonts and the axes they support.
So, back to `.fontVariations. First, let me explain the second usage,
or a string for the value of the CSS 'font-variation-settings' property
This could be used to set any variation on any axes of a variable font. For example,
"editor.fontVariations": "wdth" 93, "GRAD" 88
would translated into CSS properties
font-variation-settings: "wdth" 93, "GRAD" 88
Now back to .fontVariations: true: it's intended for use with a variable font that has a weight ("wght") axis. This doesn't seem particularly useful to me since (a) the only difference between CSS font-weight: 700 and font-variation-settings: "wght" 700 is that the latter doesn't cascade the same way, and (b) the same could be achieved by "editor.fontVariations": "wght" 700. But it appears to be another way to get the CSS property font-variation-settings: "wght" 700. (That, btw, will remove any other font-variation-settings, which is the different cascading behaviour I mentioned.)
Related
I'm writing some quizzes for Moodle using R/exams' exams2moodle. The XML file is created fine and I can import the quiz to Moodle ok, however, any question that has R code as part of either the question or the solution has the R code on a dark background making it almost impossible to read. Is there an option somewhere that controls this?
I am using this code to create the XML:
exams2moodle(c("q1.Rmd", "q2b.Rmd", "q3.Rmd", "q4.Rmd", "q5.Rmd", "q6.Rmd"),
name = "GLM_prac1",
iname = FALSE,
converter = "pandoc-mathjax",
cloze = list(cloze_schoice_display = "MULTICHOICE_V"))
And this is an example of the issue:
The color of the R code displayed is not controlled through exams2moodle(), at least not explicitly. What exams2moodle() does, is to put verbatim code input and output into standard HTML tags for this <pre><code> ... </code></pre>. This stands for pre-formatted text with markup for typewriter code. (Actually, this is not even produced by exams2moodle() directly but by pandoc.)
The rendering of these standard HTML tags is then controlled through the CSS styles employed in your Moodle installation. In a vanilla Moodle installation you currently simply get a black font on the same light blueish background as for regular text. In previous versions the background was light gray. Given that you have light orange background for text and dark background for code, I guess that this is a setting in your Moodle installation. Hence I would recommend to reach out to the Moodle team at your university and ask them about this. This seems to be a poor setting that would likely affect others as well.
If you cannot get in touch with the Moodle team or they are unwilling to change their CSS, you can insert your own custom CSS code into your exercises. The advantage is that you have full control over the color then. The disadvantage is that you yourself have to include that style code into every exercise where it is needed. It is not hard but tedious. For example, you can include the following R code chunk in the exercise directly at the beginning of the question section:
Question
========
```{r, echo = FALSE, results = "asis"}
writeLines("<style>
pre {
background: #FFFFFF00
}
</style>")
```
This simply inserts a short HTML snippet with CSS into your Rmd exercise:
<style>
pre {
background: #FFFFFF00
}
</style>
This will instruct the browser to use the background color #FFFFFF00 (fully transparent white) for all <pre>-formatted chunks. Of course, you can also play around with this and use a different color, say #EEEEEE (light gray) or similar.
I have two Shape Data rows for a Shape's ShapeSheet:
Shape Data Label Prompt Type Format Value Invisible
Prop.Type "Type" "" 4 "Alpha;Beta;Gamma;Delta;Epsilon;Zeta;Eta;Theta;Iota;Kappa" INDEX(4,Prop.Type.Format) False
Prop.Abbrev "Abbrev" No Formula 4 "A;B;G;D;E;Z;E;T;I;K" INDEX(4,Prop.Abbrev.Format) True
The way I intent to use this is to have the user select the Type, say Epsilon, and then have the Abbrev automatically switch to the corresponding value in the Prop.Abbrev.Format.
Note: the values used here are placeholders for the actual values for my application, which are not shown here so they don't distract from the real answer I need, how to keep the selections in sync when the first one is chosen or changed.
Thanks for any help you can give!
I don't have Visio on this machine, so I am unable to copy and paste a working solution. The approach gets a little complicated, but extremely flexible.
Save your lists in the User section, rather than Prop - this then becomes underlying data for use in properties. If you are using a master stencil then this also helps with managing the fields.
You can now store an index in your data as well - this index points to the appropriate values in your arrays. You can use Actions and side menus to set the index which, when referenced properly, means you can have the full name and/or abbreviation in the side menu and the ShapeSheet does all the work underneath.
The functions you want to look at are:
Index (e.g. INDEX(1,User.Type) will return "Beta". (0-based)
Lookup (e.g. LOOKUP("D", User.Abbrev) will return "3". (0-based)
GetAtRef
SetAtRef
SetAtRefExpr
SetF
I had a similar business problem which relied on setting a background colour based on the value of shape data. Your final solution could end up including formulas like this: =SETF(GetRef(Prop.Type),"GUARD(INDEX(LOOKUP(Prop.X,Prop.X.Format),User.Type))").
For more in-depth discussion - check out https://superuser.com/questions/1277331/fillforegnd-in-shapesheet-using-wrong-data and the extended discussion at http://visguy.com/vgforum/index.php?topic=8205.15 - the latter link also includes an example file with working shapesheets (well, working to the extent that they exposed my problem).
Is there currently any way I can create an extension that applies a text decorator above or below the specified range which I can use to supply any HTML/CSS visual I want?
I'm still working through the API and my guess is either no, or not directly via the extensions API.
It depends on what types of decorations you are talking about. Since you used the words "text decorator" then I'm going to assume you're talking about the decoration API described here.
As you can see, there are several css properties that they officially support, but none of them "arbitrary css".
What I've done, though, in my vscode dimmer extension, is apply an opacity style using this technique:
dimDecoration = vscode.window.createTextEditorDecorationType(<vscode.DecorationRenderOptions> {
textDecoration: `none; opacity: ${opacity / 100}`
});
When vscode sees this, it basically adds text-decoration: none; opacity: 1 to the stylesheet.This allows me to use arbitrary styling.
The above snippet creates a "Decoration" which can then be applied to ranges as shown below.
function dimEditor(editor: vscode.TextEditor) {
if (!dimDecoration) return;
let startPosition = new vscode.Position(0, 0)
let endPosition = new vscode.Position(editor.document.lineCount, Number.MAX_VALUE);
editor.setDecorations(dimDecoration, [new vscode.Range(startPosition, endPosition)]);
}
Disclaimer: Of course, this isn't officially supported and they could change the way they process the arguments to stop at the first ; and anybody using this workaround would have a broken extension.
Edit:
If you're wanting to have a "hover" behavior, there is the HoverProvider api. It can take a "marked string" which is essentially markdown, and display it. This extension uses it to display img previews on hover.
If markdown will meet your needs you can try that, otherwise you can try with arbitrary HTML and see if it accepts that.
Using TinyMCE 4.4. i like to get rid of pasted MS-Word-stuff. "paste_enable_default_filters" is a pretty tool for this. But i also like to prevent img, colors, font-size and -docorations on pasting. Since paste_enable_default_filters = true is set, paste_data_images and paste_word_valid_elements seems to be suppressed.
Any idea is welcome!
The Paste plugin has many options to help you control what is pasted and what is removed: https://www.tinymce.com/docs/plugins/paste/
In particular you may want to look at paste_word_valid_elements:
https://www.tinymce.com/docs/plugins/paste/#paste_word_valid_elements
...as this will allow you to control what tags are brought over during the paste.
You may also find value in paste_retain_style_properties:
https://www.tinymce.com/docs/plugins/paste/#paste_retain_style_properties
...as this will allow you to determine which styles should be retained during a paste.
If you want to have more control (beyond what the options on the Paste plugin perform) you can always use paste_postprocess to perform your own custom logic on the pasted content:
https://www.tinymce.com/docs/plugins/paste/#paste_postprocess
I have seen two ways to set background for Android App screen.
case A:: android:background="?attr/actionBarItemBackground"
case B:: android:background="#drawable/ic_launcher_settings"
How do android:background functions in the case A? I searched code, but not able to figure out where "actionBarItemBackground" exists. I understood case B
Case A is a reference to a style attribute. It allows you to reference a particular piece of style information without knowing its actual value. There are a lot of Android-defined attributes that are used to style the Android UI, but you can also define you own attributes.
actionBarItemBackground is one such attribute. There are two ways you can use this attribute:
You can reference it to make the look and feel of UI elements consistent with action bar items:
<com.mycompany.MyView
android:id="#+id/myView"
android:background="?attr/actionBarItemBackground"/>
You can define a theme and set the value of this attribute to override the default L&F for your app:
<style name="MyTheme" parent="#android:style/Theme">
<item name="android:actionBarItemBackground">#383c44</item>
</style>
Here are some pointers to the Android documentation:
For styles an themes see:
http://developer.android.com/guide/topics/ui/themes.html.
For a list of all attributes see:
http://developer.android.com/reference/android/R.attr.html
For defining your own attributes there is no documentation. Have a look at one of the attrs.xml files in the SDK (e.g. under platforms\android-17\data\res\values) to see how style attributes are declared. You can declare attributes in the same way by putting an attrs.xml file in your res\values folder. You can then use these attributes in your own styles and themes.