Code ^[[00;00m means reset color to default, however, in some programs (like source highlighter highlight for example) code ^[[m is used as if it would also serve the same purpose. What does ANSI state about such code, and also about similar ^[[0m?
"ANSI" in this context was obsoleted long ago by ECMA-48. So the appropriate place to start is that document.
Section 8.3.117 SGR - SELECT GRAPHIC RENDITION says
Notation: (Ps...)
Representation: CSI Ps... 06/13
Parameter default value: Ps = 0
SGR
is used to establish one or more graphic rendition aspects for subsequent text. The established aspects remain in effect until the next occurrence of SGR in the data stream, depending on the setting of the
GRAPHIC RENDITION COMBINATION MODE (GRCM). Each graphic rendition aspect is specified by a parameter value:
0
default rendition (implementation-defined), cancels the effect of any preceding occurrence of SGR in the data stream regardless of the setting of the GRAPHIC RENDITION COMBINATION MODE (GRCM)
That is, 0 is the default parameter if none is given (so ^[[m and ^[[0m mean the same thing. Repeating the parameter also makes no difference (cancelling something that was already cancelled does not uncancel it), so ^[[00;00m still means the same thing.
Related
Is there any way to set white space visible for a given scope?
I'm working on modifying a color scheme to suite my liking and would like to be able to show spaces within a given scope. I haven't seen anything suggesting it's possible within the color-scheme documentation on Sublime's website.
For my specific case, and I imagine there's other useful cases, I'm working with Markdown and want to highlight a double-space line-break. I'm able to set the background, but this doesn't look quite right. I'm hoping to be able to make whitespace visible for this small scope and change the foreground color to make it stick out.
The short answer to your question is no; or rather, Yes, but only in the way that you've already discovered.
Color schemes can only apply foreground/background colors to scopes as well as bold/italic font weights. So assuming that there is a specific scope detected by the syntax you're using that is used for the things you're trying to highlight, the only thing the color scheme can do is alter the background color to make them visible.
The only thing that can render white space natively is the draw_white_space setting, which at the moment only allows you to turn it off everywhere, turn it on everywhere, or turn it on only for selected text. In this case that doesn't really help.
There are possibilities for something like this in the plugin realm though (these examples can be tested by opening the Sublime console with View > Show Console or Ctrl+` and entering the code in there; they also assume that you're using the default Markdown syntax):
view.add_regions("whitespace", view.find_by_selector("punctuation.definition.hard-line-break.markdown"), "comment", flags=sublime.DRAW_NO_FILL)
This will cause all of the hard line breaks to be outlined as if they were find results; the color is selected by the scope (which is comment here); that would make them visible without making the whole character position have a background color.
view.add_regions("whitespace", view.find_by_selector("punctuation.definition.hard-line-break.markdown"), "comment", "dot", flags=sublime.HIDDEN)
This will add a dot (colored as a comment) in the gutter for lines that end with this scope; you can also combine this with the previous example to outline them and also call attention in the gutter.
style = '<style>.w { color: darkgray; }</style>'
content = '<body id="whitespace">' + style + '<span class="w">··</span></body>'
phantom_set = sublime.PhantomSet(view, "whitespace")
phantoms = [sublime.Phantom(r, content, sublime.LAYOUT_INLINE) for r in view.find_by_selector("punctuation.definition.hard-line-break.markdown")]
phantom_set.update(phantoms)
This uses Sublime's ability to apply inline HTML phantoms into the document in order to inject a small inline sequence of two unicode center dots immediately between the actual whitespace and the text that comes before it. Here the content can be what you like if you can generate the appropriate HTML; we're just applying a color to the text in this example.
A potential downside here is that the characters you see in the inline HTML aren't considered to be part of the document flow; the cursor will skip over them in one chunk, and they're followed by the actual whitespace.
The result of this example looks like this:
Going the plugin route, you'd need an event handler like on_load() to apply these when a file is loaded and on_modified() to re-update them after modifications are made to the buffer. There may or may not be a package that already exists that has implemented this.
I'm using ncursesw which does output some cchar_t items, everything works fine from a terminal opened in a GUI, but when on the actual PC console, the colors are off (standard simple colors) for some of the items and those do use setcchar(&cch, wch, WA_NORMAL, 0, NULL) and add_wch(&cch). The color to use is set on the window using wattrset and wbkgdset prior to the setcchar call. Is there a limitation using the wide chars (cchar_t) when dealing with a normal PC console? What would that rule be?
It turns out there was another routine that set the colorpair using setcchar and the actual attribute was used instead of the color pair number. So while some terminals must account for that, the console didn't. The proper value for setcchar is the color pair number (n) and not the result of COLOR_PAIR(n)
Using HitTestTextPosition style API from IDWriteTextLayout I did not managed to handle properly text positions inside "ti", "ffi" or other ligatures with fonts like Calibri. It always returns position after or before ligature not inside like t|i or f|f|i.
What is the recommended way to do a caret movement inside ligatures with DirectWrite API?
There... is no "inside" position if you have GSUB replacements turned on?
Opentype GSUB ligatures are single glyph replacements for codepoint sequences, rather than being "several glyphs, smushed together". They are literally distinct, single glyphs, with single bounding boxes, and a single left and right side bearing for cursor placement/alignment. If you have the text A + E and the font has a ligature replacement that turns it into Ӕ then with ligatures enabled there really are only two cursor positions in that code sequence: |Ӕ and Ӕ|. You can't place the cursor "in the middle", because there is no "middle"; it's a single, atomic, indivisible element.
The same goes for f. ligatures like ff, fi, fl, ffi, ffl, or ſt: these are single glyphs once shaped with GSUB turned on. This is in fact what's supposed to happen: having GSUB ligatures enabled means you expressly want text to be presented—for all intents and purposes—as having atomic glyphs for many-to-one substitutions, like turning the full phrase "صلى الله عليه وعلى آله وسلم", as well as variations of that, into the single glyph ﷺ.
If you want to work with the base codepoint sequences (so that if you have a text with f + f + i it doesn't turn that into ffi) you will need to load the font with the liga OpenType feature disabled.
The text editors I know of use the simple hack of (1) dividing the width of the glyph cluster by the number of code points within the cluster (excluding any zero width combining marks), rather than use the GDEF caret positioning information. This includes even Word, which you can tell if you look closely enough below. It's not precise, but since it's simple and close enough at ordinary reading sizes, it's what many do:
(2) I've heard that some may (but don't know which) also use the original glyph advances of the unshaped characters (pre-ligation) and scale them proportionally to the ligature cluster width.
(3) Some text editors may use the GDEF table, but I never knew of any for sure (possibly Adobe In-Design?).
The most challenging aspect of using methods 2 or 3 with IDWriteTextLayout is that accessing the corresponding IDWriteFontFace in that run requires quite the indirection because the specific IDWriteFontFace used (after resolving font family name+WWS+variable font axes) is stored in the layout but not publicly accessible via any "getter" API. The only way you can extract them is by "drawing" the glyph runs via IDWriteTextLayout::Draw into a user-defined IDWriteTextRenderer interface to record all the DWRITE_GLYPH_RUN::fontFace's. Then you could call IDWriteFontFace::GetDesignGlyphAdvances on the code points or IDWriteFontFace::TryGetFontTable to read the OpenType GDEF table (which is complex to read). It's a lot of work, and that's because...
The official PadWrite example has the same issue
IDWriteTextLayout was designed for displaying text rather than editing it. It has some functionality for hit-testing which is useful if you want to display an underlined link in a paragraph and test for it being clicked (in which case the ligature would be whole anyway within a word), or if you want to draw some decorations around some text, but it wasn't really intended for the full editing experience, which includes caret navigation. It was always intended that actual text editing engines (e.g. those used in Word, PowerPoint, OpenOffice, ...) would call the lower level API's, which they do.
The PadWrite sample I wrote is a little misleading because although it supports basic editing, that was just so you can play around with the formatting and see how things worked. It had a long way to go before it could really be an interactive editor. For one (the big one), it completely recreated the IDWriteTextLayout each edit, which is why the sample only presented a few paragraphs of text, because a full editor with several pages of text would want to incrementally update the text. I don't work on that team anymore, but I've thought of creating a DWrite helper library on GitHub to fill in some hindsight gaps, and if I ever did, I'd probably just ... use method 1 :b.
How can I temporarily set the colors of my Linux Terminal? I wish to add to a script, a color setting so that I remember to run the partner script a few minutes later. The color change would be set on in one script and removed in the other and would act as a visible reminder to me.
So the color change needs to be applied after the terminal is started up and needs to stay for all subsequent typing until it is removed by another equivalent command.
My terminal is GNOME Terminal 2.31.3
There's more than one way to change colors. VTE (the actual terminal within GNOME Terminal) implements these features (generally from xterm):
"ANSI color" escapes (which would be useless to you, since many programs reset those)
changing the text foreground and background using non-ANSI dynamic colors (resetters are rare)
changing the color palette (again, resetters are rare)
The latter two are documented in XTerm Control Sequences, in the section Operating System Commands:
OSC Ps ; Pt BEL
OSC Ps ; Pt ST
gives the form of the control sequence, e.g., escape]Ps;PtBEL
The dynamic colors are described here:
The 10 colors (below) which may be set or queried using 1 0
through 1 9 are denoted dynamic colors, since the correspond-
ing control sequences were the first means for setting xterm's
colors dynamically, i.e., after it was started. They are not
the same as the ANSI colors. These controls may be disabled
using the allowColorOps resource. At least one parameter is
expected for Pt. Each successive parameter changes the next
color in the list. The value of Ps tells the starting point
in the list. The colors are specified by name or RGB specifi-
cation as per XParseColor.
and other colors here:
Ps = 4 ; c; spec -> Change Color Number c to the color spec-
ified by spec. This can be a name or RGB specification as per
XParseColor. Any number of c/spec pairs may be given. The
color numbers correspond to the ANSI colors 0-7, their bright
versions 8-15, and if supported, the remainder of the 88-color
or 256-color table.
I'm interested how to construct certain kinds of layout in RTF documents, ideally using techniques that do not depend only on the most recent RTF standards, and that are "native", i.e., they do not involve embedding other representations, like picture files. In particular:
In Postscript and DVI, I can specify a coordinate at any time that the next text will be printed at: can this be done with RTF?
Can RTF compose characters through overstriking?
Can lines, outline boxes and filled boxes be drawn, with their geometry specified either absolutely, or relative to text?
You can use the \pvpg \phpg \posx123 \posy123 construct after
you start a paragraph with \pard to position it relative to the top left of the page. See: http://biblioscape.com/rtf15_spec.htm#Heading39
Yes, but it's rather involved, and I think it was only introduced in RTF 1.5. See the drawing objects section of the spec. Here is a basic example of drawing a box (I'm not sure it's entirely valid but it should give you an idea of how to work with drawing objects):
{\rtf1\ansi\deff0
{\pard {\*\do
\dobxcolumn \dobypara
\dprect \dpx0 \dpy0 \dpxsize1000 \dpysize1000 \dplinew25
}\par}
}
If you're doing any work with RTF it's worth picking up O'Reilly's RTF Pocket Guide.
I don't believe this is possible. You'd need to use tabs and newlines to get the text where you want it.
Not really, unless \strike and \strikedl count.
http://www.biblioscape.com/rtf15_spec.htm#Heading52 says drawing objects are an option, and so is inserting images, but neither are really "native", both being absent in the first RTF specs. (And the latter is a bad choice for i.e. just a line.)