Spec for font configuration objects #10383

PankajBhojwani · 2021-06-09T18:41:32Z

Summary of the Pull Request

Spec for #6049

Keeping this in draft because there are issues that need to be figured out (noted in the comments)

PR Checklist

Detailed Description of the Pull Request / Additional comments

Read the spec!

github-actions · 2021-06-09T18:44:03Z

@check-spelling-bot Report

Unrecognized words, please review:

preseved
unavaoidable

Previously acknowledged words that are now absent

hpcon serializers Tlg

To accept these unrecognized words as correct (and remove the previously acknowledged and now absent words), run the following commands

... in a clone of the git@github.com:microsoft/terminal.git repository
on the dev/pabhoj/font_config_spec branch:

update_files() {
perl -e '
my @expect_files=qw('".github/actions/spelling/expect/alphabet.txt
.github/actions/spelling/expect/expect.txt
.github/actions/spelling/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"$patch_remove"');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
next if /^(?:$re)(?:(?:\r|\n)*$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spelling/expect/94d39b75805a4c2728cb67f2f8c312730a68dc75.txt";
use File::Path qw(make_path);
use File::Basename qw(dirname);
make_path (dirname($new_expect_file));
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"$patch_add"');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a)."-".$a cmp lc($b)."-".$b} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;
system("git", "add", $new_expect_file);
'
}

comment_json=$(mktemp)
curl -L -s -S \
  --header "Content-Type: application/json" \
  "https://api.github.com/repos/microsoft/terminal/issues/comments/857971196" > "$comment_json"
comment_body=$(mktemp)
jq -r .body < "$comment_json" > $comment_body
rm $comment_json

patch_remove=$(perl -ne 'next unless s{^</summary>(.*)</details>$}{$1}; print' < "$comment_body")
  

patch_add=$(perl -e '$/=undef;
$_=<>;
s{<details>.*}{}s;
s{^#.*}{};
s{\n##.*}{};
s{(?:^|\n)\s*\*}{}g;
s{\s+}{ }g;
print' < "$comment_body")
  
update_files
rm $comment_body
git add -u

✏️ Contributor please read this

By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.

⚠️ The command is written for posix shells. You can copy the contents of each perl command excluding the outer ' marks and dropping any '"/"' quotation mark pairs into a file and then run perl file.pl from the root of the repository to run the code. Alternatively, you can manually insert the items...

If the listed items are:

... misspelled, then please correct them instead of using the command.
... names, please add them to .github/actions/spelling/allow/names.txt.
... APIs, you can add them to a file in .github/actions/spelling/allow/.
... just things you're using, please add them to an appropriate file in .github/actions/spelling/expect/.
... tokens you only need in one place and shouldn't generally be used, you can add an item in an appropriate file in .github/actions/spelling/patterns/.

See the README.md in each directory for more information.

🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉

🗜️ If you see a bunch of garbage

If it relates to a ...

well-formed pattern

See if there's a pattern that would match it.

If not, try writing one and adding it to a patterns/{file}.txt.

Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

Note that patterns can't match multiline strings.

binary-ish string

Please add a file path to the excludes.txt file instead of just accepting the garbage.

File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

doc/specs/#6049 - Font config objects.md

PankajBhojwani · 2021-06-09T18:47:49Z

doc/specs/#6049 - Font config objects.md

+
+## Future considerations
+
+Similar to the discussion we had regarding appearance configurations, we will need to figure out how we want to deal with overlapping configurations. I.e. if font configurations are defined for both bold and italic, how should font that is both bold and italic be handled?


I am tempted to say that this issue is much more pressing when it comes to fonts than it was for appearance configurations, to the point where I wonder if we should decide not to proceed further with this until we figure this out

Technically, text can't be both bold and italic, right? Because terminals would only say if text should be "more bright" or "more faint", I think? But I'm also confused because the API for TextAttribute has IsBold and IsFaint as two separate variables, so theoretically somebody could call SetIsBold(true) and SetIsFaint(true) back to back, right?

Dumb idea, if text is both "more bright" and "more faint", would that mean that it negates itself and you just see text at normal brightness? In other words, would IsBold() && IsFaint() mean that we should just use the default font config?

I think text can be both bold and italic, try doing:

echo ^[[1;3m in command prompt, you get text that's both bold and italic

Oof. We almost need people to be able to define a "BoldItalic" variant too.

mdtauk · 2021-06-09T18:53:06Z

Are you able to detect Stylistic Sets, and display buttons to toggle them on and off when they are detected in the chosen font?

doc/specs/#6049 - Font config objects.md

carlos-zamora · 2021-06-09T22:59:57Z

doc/specs/#6049 - Font config objects.md

+"boldFont":
+{
+    "fontFace": "Consolas",
+    "fontWeight": "Extra-Bold"
+}


wait... we ~~can~~ will be able to do this? Use multiple fonts within the same text buffer? (important for me to know for my a11y text attributes PR haha)

You know what, let me test that out and get back to you

Tested it, and short answer: yes we can have multiple fonts in the same text buffer

Long answer: there's funky stuff that goes on because of the different fonts not necessarily having the same glyph size and so the spacing becomes weird - we should be able to do some creative scaling to avoid this problem though

doc/specs/#6049 - Font config objects.md

carlos-zamora · 2021-06-09T23:16:03Z

doc/specs/#6049 - Font config objects.md

+
+## Future considerations
+
+Similar to the discussion we had regarding appearance configurations, we will need to figure out how we want to deal with overlapping configurations. I.e. if font configurations are defined for both bold and italic, how should font that is both bold and italic be handled?


Technically, text can't be both bold and italic, right? Because terminals would only say if text should be "more bright" or "more faint", I think? But I'm also confused because the API for TextAttribute has IsBold and IsFaint as two separate variables, so theoretically somebody could call SetIsBold(true) and SetIsFaint(true) back to back, right?

miniksa · 2021-06-10T17:22:24Z

doc/specs/#6049 - Font config objects.md

+    "fontWeight": "Normal",
+    "fontSize": 12
+},
+"boldFont":


Would it make more sense visually in the JSON to imply the hierarchy with something like:

"font": { "face" : "Cascadia Mono", "weight" : "Normal", "size" : 12, "variants": [ "bold" : { "face" : "Consolas", "weight" : "Extra-Bold" }, "italic" : { "weight" : "Light" } ] }

Hmmmmm very interesting. Would any key in font be available to variants? So somebody could set font:face:Cascadia font:variants:bold:face:Consolas?

I kinda like this

Hmmmmm very interesting. Would any key in font be available to variants? So somebody could set font:face:Cascadia font:variants:bold:face:Consolas?

Of the 3 keys available now, weight, face, and size, only size will be disallowed to variants (we don't want weird resizing from different parts of the text being bold or something)

miniksa · 2021-06-10T17:23:58Z

doc/specs/#6049 - Font config objects.md

+
+### Compatibility
+
+This feature changes the way we expect to parse font settings. However, we have to make sure we are still able to parse font settings the way they are currently, so as to not break functionality for legacy users.


Do we have precedent for a settings-file-rewriter that pre-passes legacy configs and just rewrites them into the current format? (Instead of leaving multiple parse-mechanisms in the current format loader?)

We don't, but it is probably a good idea.

PankajBhojwani · 2021-06-11T15:46:04Z

Update: for now we are going to move away from this design and focus on how users can configure feature flags (i.e. picking stylistic sets, whether ligatures are enabled etc) and axes for their fonts.

first draft

b465e8f

PankajBhojwani commented Jun 9, 2021

View reviewed changes

doc/specs/#6049 - Font config objects.md Show resolved Hide resolved

PankajBhojwani commented Jun 9, 2021

View reviewed changes

spell

6aa0f56

carlos-zamora reviewed Jun 9, 2021

View reviewed changes

miniksa reviewed Jun 10, 2021

View reviewed changes

visual hierarchy, null option, rewriter

40518f4

PankajBhojwani closed this Jun 11, 2021

carlos-zamora mentioned this pull request Jun 24, 2021

Group font options in the json into a single object #10433

Merged

6 tasks

DHowett deleted the dev/pabhoj/font_config_spec branch October 26, 2021 16:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Spec for font configuration objects #10383

Spec for font configuration objects #10383

PankajBhojwani commented Jun 9, 2021

github-actions bot commented Jun 9, 2021 •

edited

Loading

PankajBhojwani Jun 9, 2021 •

edited

Loading

carlos-zamora Jun 9, 2021

carlos-zamora Jun 9, 2021

PankajBhojwani Jun 10, 2021

miniksa Jun 10, 2021

mdtauk commented Jun 9, 2021

carlos-zamora Jun 9, 2021

PankajBhojwani Jun 10, 2021

PankajBhojwani Jun 10, 2021

carlos-zamora Jun 9, 2021

miniksa Jun 10, 2021

DHowett Jun 10, 2021

DHowett Jun 10, 2021

PankajBhojwani Jun 10, 2021 •

edited

Loading

miniksa Jun 10, 2021

DHowett Jun 10, 2021

PankajBhojwani commented Jun 11, 2021


		## Future considerations

		Similar to the discussion we had regarding appearance configurations, we will need to figure out how we want to deal with overlapping configurations. I.e. if font configurations are defined for both bold and italic, how should font that is both bold and italic be handled?


		### Compatibility

		This feature changes the way we expect to parse font settings. However, we have to make sure we are still able to parse font settings the way they are currently, so as to not break functionality for legacy users.

Spec for font configuration objects #10383

Spec for font configuration objects #10383

Conversation

PankajBhojwani commented Jun 9, 2021

Summary of the Pull Request

PR Checklist

Detailed Description of the Pull Request / Additional comments

github-actions bot commented Jun 9, 2021 • edited Loading

@check-spelling-bot Report

Unrecognized words, please review:

PankajBhojwani Jun 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdtauk commented Jun 9, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PankajBhojwani Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PankajBhojwani commented Jun 11, 2021

github-actions bot commented Jun 9, 2021 •

edited

Loading

PankajBhojwani Jun 9, 2021 •

edited

Loading

PankajBhojwani Jun 10, 2021 •

edited

Loading