By default MacOS's built in QuickLook feature displays only latin characters + figures when previewing font files. This is what it looks like:
typical QuickLook preview window for a font file
I need to be able to quickly see if the font contains non-latin characters, for example Cyrillic. I am sure there is a way to edit some .plist file inside macOS to modify the list of characters that QuickLook shows for a font in order to add some non latin characters. I even did it once, but it was a few releases of MacOS ago, when System and Library folders were not hidden and thus were searchable.
Could someone please advise, where this .plist file may be located now in MacOS (HighSierra)? Thanks!
Found a solution myself:
The various character sets that QuickLook presents are based on the language which is the primary language you are using. The character sets are are kept in a file called SampleSupport.plist which is found at:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/Resources
Copy this path and in Finder go: Command + Shift + G and paste the path into the field and you will instantly brought to the right place.
Edit the file in your favourite editor. Edit the EN char string to add some non-latin chars.
editing SampleSupport.plist to show non-latin characters
Related
I am trying to open a .log file while in Sublime Text 3 (v3.2.2, Build: 3211) installed on Mac OS Catalina and I see that it opens with plain hex numbers.
This is a small snippet:
205b 6465 6275 675d 2031 3631 3736 2330
3a20 6570 6f6c 6c20 7469 6d65 723a 202d
I am not sure why this happens but I am not able to see any quick link for the same anywhere for this issue.
This is an indication that Sublime thinks that the file that you tried to open is a binary file; it's controlled by this setting (which as seen here defaults to true):
// Files containing null bytes are opened as hexadecimal by default
"enable_hexadecimal_encoding": true,
When this is turned on, the file is opened using the Hexadecimal encoding as a warning to you that the file is (or seems to be) a binary file. If the file is actually binary, then you probably don't want to be editing it with a text editor.
On the flip side, if the file is actually a text file with something in it that makes it detect as binary, then it's possible that the detection of what encoding the file is actually using may not work the way you expect, which can cause other issues. So in that case the setting opens the file in Hexadecimal as a warning to you that you need to tell Sublime what encoding it should be using.
If you're sure the file is actually a text file (probably a good guess for a .log file), then you can use File > Reopen with encoding to tell Sublime that it should be using a different encoding, for example utf-8. You can also try turning off the above setting so that this doesn't happen, although in that case as mentioned the encoding that's selected may be incorrect.
Related to this, there's another setting that can come in handy:
// Display file encoding in the status bar
"show_encoding": false,
This one defaults to false, but when you turn it on the encoding of the current file appears in the status bar on the right hand side, near where you see the indent settings and the type of the current file.
If this is turned on, you can easily verify exactly what encoding is currently being used, and you can also click there to get a menu that lets you change the encoding of the current file or quickly re-open it using a different encoding.
I am trying to create a test csv file for a file cleaning script that is supposed to normalize all whitespace into "normal"/ "regular" whitespace character. The idea is I will insert a bunch of these oddball whitespace characters into this test file in some various locations.
Here are some sites that show these various and oddball whitespaces
https://en.wikipedia.org/wiki/Whitespace_character
http://jkorpela.fi/chars/spaces.html
I've tried to copy and paste from sources like that website but it seems like they always paste in as a normal space in Textmate. It could be that I am not copying what I think I am copying. In the past I've been able to copy and paste into Textmate special / unicode characters when I can clearly see what I am copying but with whitespace characters, I can't confirm since I can can't see it, so I am not sure if the problem is where I am copying from or that Textmate is converting it to the normal space when I paste it in.
If it is easier to use Textedit (the built in editor) or nano (command line editor) to do this I could use those. Or if there is another way other than copying and pasting that is better to get these into Textmate that would be an option.
I am on a MacbookPro running High Sierra MacOS.
If you have LibreOffice installed you can use the spreadsheet application to create these using their hexidecimal equivalent in 1 cell then doing a conversion using
=unichar(hex2dec(cell_ref_to_1rst_cell)).
Far less confusing and you can save the spreadsheet complete with comments as a handy reference. Then you should just be able to copy paste the cell with the unicode character when required.
If you’re using TextMate, various functions provided by the Unicode bundle could be helpful here (install via Preferences → Bundles → Unicode).
With this bundle installed you can use Insert Unicode Character ⌃⌥⌘I to insert a character by name. Search for “space” to get a list of all space characters, then simply click on the desired character (the full title of a character is shown on hover):
Of course once inserted all the space characters look almost identical. To identify them, use Show Unicode Name(s) ⌃⌥⌘U 6. This will display a tooltip showing the unicode of name of the character directly before the cursor (or the names of all selected characters, if a selection is active).
Also have a look at Show Character Inventory (press ⌃⌥⌘U and then select the command from the popup menu): This provides a convenient overview of all the characters in your document (or in the selected text, if a selection is active).
I have a big project with lots of text stored both in labels in storyboard and variables. I know how to localize text in labels, but have no idea how to localize string variables. Can you explain that or give a link to the guide. I'm using Xcode version 6.2
In code, you use NSLocalizedString() with your base language:
NSLocalizedString("This is my text", comment: "Label in mainView")
The comment can be left empty "" but it is useful for the translator (even if this is you) to know where the string comes from.
Xcode automatically creates a file Localizable.strings in your project in a subfolder for the language. The file contains entries like that:
/* Label in mainView */
"This is my text" = "Dies ist mein Text";
You can translate the strings in that file with a text editor of your choice.
A better way to work with translations is to select the project target in Xcode, then choose from the menu
Editor->Export For Localization...
This will create a folder in a location of your choice containing a language file in xliff format, i.e. for german: de.xliff
xliff is a standardized (XML) format. It is somewhat hard to edit that file in a simple text editor. I use iXLIFF for that. It is a very small application for the Mac and makes translations a breeze.
After translating the xliff file go to Xcode
Editor->Import Localizations...
and choose the xliff file. Xcode will tell you when something is missing.
I use a text file (History.txt) for notes and to keep track of my edits. Xcode 6 is applying the indentation rules to all files, and so manual formatting (using tabs) in my text file is changed when I type a line or copy and paste. For example, typing a semicolon causes a line with leading whitespace to left justify. Prior versions of Xcode didn't do this.
I must have autoindent on for my source code files.
How can I tell Xcode 6 to leave my .txt files alone (no auto indent)?
I had the exact same problem. Didn't find a proper solution, but a workaround is to turn off the auto-indent feature (under Preferences -> Text Editing -> Indentation) for the specific characters that you use a lot in your text files (in my case the colon character was the main culprit) and that you can learn to live without having auto-indent when actually editing code. It's a decent way to get around this problem.
Years ago, I was messing around with Visual Basic and I discovered a bug with the MsgBox function. I tried searching for it, but nobody had ever said anything about it. It's not just with Visual Basic though; it's with anything that uses the standard Windows MessageBox API call.
The bug is triggered when the title text has more than one character, and the first character is a lowercase 'y' with an umlaut ('ÿ'). What's so special about this character? It almost definitely not the character itself, but rather its ASCII value that's special. 'ÿ' is character 255 (0xFF), meaning it's the highest value that can be stored in an unsigned byte, and all its bits are set to 1.
What does this bug do? Well, there are two different possibilities, which depend on the number of characters in the title text. If there are an even number of characters (unless it's 2) in the title text, no message box appears, and you just hear the alert sound. If there are two characters in the title text, or any odd number other than 1 (in which case the bug wouldn't be triggered)...then this happens:
And that's not all--the message will also be truncated to one line. It seems like the kind of bug that would occur in at least one semi-high-profile incident, considering how often this API call is used. Are there any reports of this on the Internet, or anything showing what could cause it? Maybe it's a Unicode-related glitch, like that "bush hid the facts" glitch in Notepad?
I made a program in case you want to play around with this; download it here.
Alternatively, copy the following into Notepad, save it with a .vbs extension, and double-click it to display the dialog box seen above:
MsgBox "Windows 3.1 font, anyone?", 0, "ÿ ODD NUMBER!"
Or for a different font:
MsgBox "I CAN HAS CHEEZBURGER?", 0, "ÿ HImpact"
EDIT: It seems that if the first four characters are ÿ's, it doesn't ever display the message, even if there's an odd number of characters.
This is a bug with dialog templates generally. It is not a message box bug as such.
For example, in Visual Studio create the default win32 application. In the .rc file, change the caption in the template for the about box from
CAPTION "About sampleapp"
to
CAPTION "ÿT"
and the bug will manifest itself when you display the about box.
In the DLGTEMPLATEEX documentation note that the menu and class name have type sz_Or_Ord which means either a null-terminated string or 0xFFFF followed by a single word resource identifier.
Windows incorrectly applies a similar scheme to the dialog title: if the first character is 0xFF then it treats the title as being two WORDs long, but only when it is trying to locate the font information. When it is displaying the title it correctly treats the title as a string.
In other words, Windows is looking for the font information inside the title string. In most case this won't specify a valid font, so Windows defaults to the system font.
To prove this, I constructed a dialog template in memory (based on this). Once this was working I deleted the code that writes the font information to the template and used the dialog title "ÿa\xd\x200\x21SimSun". This displays the dialog in italic SimSun because windows is reading the font information from the title string.
This bug is likely a hangover from 16-bit Windows, where (I guess) 0xFF was used as the resource ID marker.
A strange bug. I suspect the symptoms are the result of the way the MessageBox() actually displays the dialog.
Internally, MessageBox() builds a dialog template dynamically. If you look at the description of a DLGTEMPLATE structure you'll find the following nugget of information:
In a standard template for a dialog box, the DLGTEMPLATE structure is
always immediately followed by three variable-length arrays that
specify the menu, class, and title for the dialog box. When the
DS_SETFONT style is specified, these arrays are also followed by a
16-bit value specifying point size and another variable-length array
specifying a typeface name.
So, the in-memory layout of a dialog template has the font specification immediately following the dialog box title.
Visual Basic does not use Unicode and so the function you're calling is actually MessageBoxA(). This is simply a thunk that converts the passed-in strings from multibyte to Unicode and then calls MessageBoxW().
I believe what's happening is that, for some reason, the conversion of that string from multibyte to Unicode is either going wrong, or returning a spurious length value. This has the knock-on effect, when the dialog template is built in memory, of corrupting the memory immediately following the title string - which, as we know, is the font specification.