I noticed that Sublime Text has much better rendering for some fonts and sizes than Scintilla based editors. How is that achieved? Is there some famous text renderer underneath it or they developed their own?
Sublime Text uses highly tuned settings over platform-specific libraries to render text. It has actually used several different libraries throughout the years. I couldn't find any specifics for OSX, but there are some details for Windows/Linux in the forums and release notes.
In ST3 build 3034, it is noted that the graphics rendering engine was "ported to Skia from Cairo". However, it is not clear if there was custom text rendering being done, or if it is just for UI elements.
Sublime Text 1
I can't find a good reference for version 1, but through bits and pieces of forum conversations, it looks like it may have been a custom rendering engine written on top of OpenGL. Other forum posts point out that all future rendering would be pure software as there was a lot of cross-platform issues caused by GPU rendering.
The best quote I could find was this:
Sublime Text 2 uses software rendering only. Ultimately, it caused too many compatibility issues in 1.x, and with going cross platform for version 2, that would only have increased. Nonetheless, I'll talk about Sublime Text 1.x for a bit.
The basic text rendering itself was fairly standard: textured quads are drawn to the screen, one per character. However, there are a few details worth noting:
* Characters are buffered, and sorted by color, to reduce state changes.
* Most OpenGL applications will have a single channel texture for the characters, and blend the desired color on top. Sublime Text uses RGB textures, with the text pre-composed with the correct foreground and background color. This takes more memory, but allows ClearType to be used, which is important for a text editor.
Sublime Text 2 (release notes)
Windows uses GDI, with an option added in build 2081 to use DirectWrite instead.
In build 2170, Pango was added as the rendering on Linux to improve support for cjk text.
Sublime Text 3 (release notes)
DirectWrite replaced GDI as the default renderer on Windows in build 3127, unless you are using the fonts Consolas or Courier New. GDI was kept as a rendering option in the settings.
Related
I wrote a script which parses information from PDF files and outputs it to HTML. It's written in Python, using pdfminer.
On some text segments, the font style can have semantic significance. For instance: bold, italic and color should trigger different behavior. Pdfminer provides scripts with the font name, but not the color, and it has a number of other issues; so I'm working on a Swift version of that program, using Apple's PDFKit, to extract the same features.
I now find that I have the opposite problem. While PDFKit makes it easy to retrieve color, retrieving the original font name seems to be non-obvious. PDFSelection objects have an attributedString property, but for fonts that are not installed on my computer, the NSFont object is Helvetica. Of course, the fonts in question are fairly expensive, and acquiring a copy just for this purpose would be poor form.
Short of dropping to CGPDFContentStream (which is way too big of a hammer for what I want to get), is there a way of getting the original font name? I know in advance what the fonts are going to be, can I use that to my advantage?
PDFKit seems to use the standard font lookup system and then falls back on some default, so this can be resolved by spoofing the font to ensure that PDFKit doesn't need to fall back. Inspecting the document, I was able to identify that it uses the following fonts (referenced with their PostScript name):
"NeoSansIntel"
"NeoSansIntelMedium"
"NeoSansIntel,Italic"
I used a free font creation utility to create dummy fonts with these PostScript names, and I added them to my app bundle. I then used CTFontManagerRegisterFontsForURLs to load these fonts (in the .process scope), and now PDFKit uses these fonts for attributed strings that need them.
Of course, the fonts are bogus and this is useless for rendering. However, it works perfectly for the purpose of identifying text that uses these font.
This is the closest I've seen to that, and even it doesn't do a particularly good job; it certainly doesn't integrate (if it can even be said to do so) as well as the the highlight.js blocks reveal.js supports by default (which aren't responsive and lack a bunch of the other nice features of ACE).
I tried naively embedding an ACE textbox in a slide myself, and it didn't work out well. Reveal changed the size of the thing, but even after fixing that (and setting "text-align:left") the visual cursor didn't align with the actual cursor, and the editor warning icon was tiny.
The problem with ACE and reveal.js is the are the css attributes zoom or transform: scale() which reveal uses to fit the content to the screen. ACE requires pixel fonts and does not use the scaling in calculating mouse cursor positions.
I made a small fork and added a reval.js specific check for the editor.
see https://github.com/waywaaard/ace
https://github.com/waywaaard/ace/commit/e4e3da28515ef7a58fe85378dd4dd557918fc4a6
This fixes the problem for my use cases.
My way of solving those issues is embedding ACE in an iframe instead of using it directly. I wrote a reveal.js plugin that makes embedding an ACE editor easy:
https://github.com/Gottox/reveal.js-ace
I'd like to change the background color and text color programmatically in PDF documents so that they're nicer to read at night (kinda like in Adobe Reader: Edit -> Preferences -> Accessibility -> Replace Document Colors).
Is there any good command line tool or API for Windows that can do that?
So far I haven't found any. It's OK if it needs to save the newly colored PDF into a new file.
There is no way to do this directly, with no (Free Software or gratis) tool I'm aware of. (Because in the general case, you'll have to change all colors of the PDF pages, not just the background alone, so you can still have some contrast and color differences.)
What you describe for Adobe Reader does not change the PDF file itself, it changes the way the application renders the pages (by inverting colors, or similar). The PDF remains the same during and after viewing it.
However, you might be able to achieve a similar thing by applying a suitable ICC color profile to the input PDF and produce, with the help of (a very recent version of) Ghostscript, a new output PDF from this.
The question would remain: what IS a "suitable" ICC color profil for your purpose??
I've shortly considered to apply a gray-ish background to the PDF with the help of pdftk ... background ... command line. But this would probably make some or many PDFs unreadable. (A black background would surely make it unreadable, because most text is black and would remain so.)
To create a PDF page (A4 size) which could serve as the gray background, you could use Ghostscript: gs -o gray.pdf -sDEVICE=pdfwrite -g5950x8420 -c ".8 setgray 0 0 595 842 rectfill showpage".
Then apply it to your original PDF (A4): pdftk original.pdf background gray.pdf output orig-with-backgr.pdf.
Note, this will only change the background of these pages (or those areas of pages), where the original background is transparent, as most text-based PDFs are. It will not work for pages or areas where the background is opaque white or color.)
You can also achieve a permanent color change (inverse colors) quite easily with the help of ImageMagick. But this will at the same time munch and make mincemeat of your nice vector PDFs, converting them into complete-raster image pages: convert nice.pdf -alpha off -invert inverted-colors-ugly-raster.pdf.
Finally, here is a rather unreliable way to accomplish the inverting of colors with the help of Ghostscript. It sets up a colortransfer function for the output PDF file:
gs -o output.pdf \
-sDEVICE=pdfwrite \
-c "{1 exch sub}{1 exch sub}{1 exch sub}{1 exch sub} setcolortransfer" \
-f input.pdf
It is unreliable, because not every PDF viewer will honor that setting. I've tested it a few times in the past...
These viewers DO SHOW inverted colors:
Adobe Reader
Adobe Acrobat
gv
Ghostscript/gs
Chrome's native PDF renderer ('pdfium')
These ones DON'T SHOW inverted colors:
Chrome with PDF.js
Firefox with PDF.js
Zathura
MuPDF
Just in case the OP doesn't really need to change the PDF document colors permanently, but only wants a PDF viewer other than Acrobat that can do similarly change the displayed colors...
MuPDF: MuPDF is a lightweight PDF viewer (amongst other things). It can invert the displayed colors with the simple stroke of the i for any document while it is open. MuPDF is also available for Windows (and iOS, and Android, and OSX, and Linux). (It is made by the same company which brought us Ghostscript).
MuPDF screenshots here: "normal" view (left) and "inverted" view (right)
SumatraPDF: This is a very popular alternative PDF viewer for Windows. Its PDF rendering engine is based on MuPDF. Hitting . in presentation mode, it changes background to black. Hitting w in presentation mode, it changes background to white. (I don't think it can also invert all colors, but I do not have the latest release available right now to check.) For startup adding -invert-colors to the command line, it will invert the colors for the rendered document.
Zathura: A lightweight PDF viewer for Linux and OSX, which can be controlled by Vim-like keyboard shortcuts. ctrl+r will re-color the rendering of any opened document. Background will change to dark, texts will change to bright gray (however it will not invert a, say blue text to yellow, like MuPDF does). I'm not sure if it is available on Windows too.
Evince: The Gnome PDF viewer, available for Linux, OSX and Windows. It can invert the colors of the open document too; the keyboard shortcut is ctrl+i.
XPDF: XPDF is quite an ancient PDF viewer for Unix + Linux (not sure if there is a Windows version available -- maybe in Cygwin). It has a startup option in its command line: xpdf -rv -papercolor "#333333" file.pdf will invert the colors (-rv is for reverse video, -papercolor lets you change the background to something different from pure black [as any inverted white would become]).
As you asked for an API, I'll throw one additional possibility in the mix. It is actually possible to write a plug-in for Adobe Acrobat (should be possible for Adobe Reader too, but Reader plug-ins are more difficult) that interferes with display.
A long time ago I wrote code for Enfocus PitStop to implement a wireframe rendering mode for PDF files inside of Adobe Acrobat. Click a button and the display changes to wireframe, click again and you have your normal view. This works because you can (as a plug-in) modify the display list (the list of objects) drawn by Acrobat.
This means that to draw your special display mode you could create a new display list (or modify the existing one) so that it has a rectangle at the very back in the color that you want and then modify the color of all objects in the display list to suit your needs.
This is relatively complex as it is, what makes it more complex is that - if you don't want your changes to affect the PDF file on disk, you have to intercept a myriad of Acrobat notifications and undo your changes. For example, if the user attempts to save the PDF document while viewing in your display mode, you have to make sure you are warned about that and undo the changes during the save. Adobe Acrobat makes this possible because it sends you notifications before and after the save process but it's still a serious job to make sure nothing gets screwed up.
But it's a absolutely cool and very flexible way to implement what you were after. Just make sure you have more than a couple of weeks to implement it :)
Install nodejs.
npm i -g serve
In directory with pdfs run: serve
Open http://localhost:5000 in Chrome and click on some file.
Install Chrome extension Dark Reader
Dark Reader > Toggle localhost:5000
This picture illustrates my predicament:
All of the characters appear to be the same size, but the space between them is different when presented in a RichEdit control compared with when I use ExtTextOut.
I would like to present the characters the same as in the RichEdit control (ideally), in order to preserve wrap positions.
Can anyone tell me:
a) Which is the more correct representation?
b) Why the RichEdit control displays the text with no gaps between the Asian Characters?
c) Is there any way to make ExtTextOut reproduce the behaviour of the RichEdit control when drawing these characters?
d) Would this be any different if I was working on an Asian version of Windows?
Perhaps I'm being optimistic, but if anyone has any hints to offer, I'd be very interested to hear.
In case it helps:
Here's my text:
快的棕色狐狸跳在懶惰狗1 2 3 4 5 6 7 8 9 0
apologies to Asian readers, this is merely for testing our Unicode implemetation and I don't even know what language the characters are taken from, let alone whether they mean anything
In order to view the effect by pasting these characters into a RichEdit control (eg. Wordpad), you may find you have to swipe them and set the font to 'Arial'.
The rich text that I obtain is:
{\rtf1\ansi\ansicpg1252\deff0\deflang2057{\fonttbl{\f0\fnil\fcharset0 Arial;}}{\colortbl ;\red0\green0\blue0;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\fs22\u24555?\u30340?\u26837?\u33394?\u29392?\u29432?\u36339?\u22312?\u25078?\u24816?\u29399?1 2 3 4 5 6 7 8 9 0\par\pard\'a3 $$ \'80\'80\cf1\lang2057\fs16\par}
It doesn't appear to contain a value for character 'pitch' which was my first thought.
I don't know the answer, but there are several things to suspect:
There are several versions of the rich edit control. Perhaps you're using an older one that doesn't have all the latest typographic improvements.
There are many styles and flags that affect the behavior of a rich editcontrol, so you might want to explore which ones are set and what they do. For example, look at EM_GETEDITSTYLE.
Many Asian fonts come in two versions on Windows. One is optimized for horizontal layout, and the other for vertical layout. That latter usually has the same name, but has # prepended to it. Perhaps you are using the wrong one in the rich edit control.
UPDATE: By messing around with Wordpad, I was able to reproduce the problem with the crowded text in the rich edit control.
Open a new document in Wordpad on Windows 7. Note that the selected font is Calibri.
Paste the sample text into the document.
Text appears correct, but Wordpad changed the font to SimSun.
Select the text and change the font back to Calibri or Arial.
The text will now be overcrowded, very similar to your example. Thus it appears the fundamental problem is with font linking and fallback. ExtTextOut is probably selecting an appropriate font for the script automatically. Your challenge is to figure out how to identify the right font for the script and set that font in the rich edit control.
This will only help with part of your problem, but there is a way to draw text to a DC that will look exactly the same as it does with RichEdit: what's called the windowless RichEdit control. It not exactly easy to use: I wrote a CodeProject article on it a few years back. I used this to solve the problem of a scrollable display of blocks of text, each one of which can be edited by clicking on it: the normal drawing is done with the windowless RichEdit, and the editing by showing a "real" RichEdit control on the top of it.
That would at least get you the text looking the same in both cases, though unfortunately both cases would show too little character spacing.
One further thought: if you could rely on Microsoft Office being installed, you could also try later versions of RichEdit that come with office. There's more about these on Murray Sargent's blog, as well as some interesting articles on font binding that might also help.
ExtTextOut allows you to specify the logical spacing between records. It has the parameter lpDx which is a const pointer to an array of values that indicate the distance between origins of adjacent character cells. The Microsoft API documentation notes that if you don't set it, then it sets it's own default spacing. I would have to say that's why ExtTextOut is working fine.
In particular, when you construct a EMR_EXTTEXTOUTW record in EMF, it populates an EMR_TEXT structure with this DX array - which looking at one of your comments, allowed the RichEdit to insert the EMF with the information contained in the record, whereby if you didn't set a font binding then the RTF record does some matching to work out what font to use.
In terms of the RichEdit control, the following article might be useful:
Use Font Binding in a Rich Edit Control
After character sets are assigned, Rich Edit scans the text around the
insertion point forward and backward to find the nearest fonts that
have been used for the character sets. If no font is found for a
character set, Rich Edit uses the font chosen by the client for that
character set. If the client hasn't specified a font for the character
set, Rich Edit uses the default font for that character set. If the
client wants some other font, the client can always change it, but
this approach will work most of the time. The current default font
choices are based on the following table. Note that the default fonts
are set per-process, and there are separate lists for UI usage and for
non-UI usage.
If you haven't set the characterset, then it further explains that it falls back to ANSI_CHARSET. However, it's most definitely a lot more complicated than that, as that blog article by Murray Sargent (a programmer at Microsoft) shows.
What are the recommended colors for an application's background, button faces, etc.?
In the past I've just chosen a color scheme but I'd like to be more compatible with the Windows Accessibility Options, etc.
I see that VB6 has System Colors like Application Workspace.
Edit: I'd like to find an explanation of all of those colors (like what's the difference between Application Workspace and Window Background?
In my opinion, you should leave the colors as they are if you are using standard controls; they'll get the right color according to che current color scheme by themselves. You need to use the color constants only if you have to draw your own UI elements; in that case, the meaning of those constants is explained briefly in their documentation.
This PDF http://www.johnsmiley.com/cis18/Smiley009.pdf [ explanation of VB6 System Color values ]should help you. It lists all the system color constants and what they mean. For instance vbApplicationWorkspace is the "Background color of multipledocument interface (MDI) applications."
If you're interested in the whole MS Windows UI/UX guidelines, they are available online here and for download here. Page 618 deals with how to "Use theme or system Colors"
It depends on the language and framework you use. .Net for example has an entire SystemColors class full of static properties like SystemColors.Control that are 'changed' to the corresponding system color in runtime.
I think most office applications conform to the system colors, while most graphics intensive applications (e.g. games) use their own color scheme.
It is best if you try to use the colors of the current system (like the .NET SystemColors), that way if the user changes his settings (for example if he uses a high-contrast color scheme or some fancy black theme he likes) your application will adapt those colors and that way conforms to the users preferences/needs.