I am using Lilypond 2.22.2 on Windows 10 and I have the following code as header (the title and the composer is in greek language):
\header {
title = "Που 'σαι Λάζαρε"
composer = "παραδοσιακό"
}
After compilation I get the following warning and the letter Π (the capital Pi) is missing in the pdf file. All the other letters are displayed correctly.
no glyph for character U+FFFD in font `C:/Program Files (x86)/LilyPond/usr/share/lilypond/current/fonts/otf/C059-Roman.otf'
The ly file is in UTF-8 encoding. Can anyone help me?
Related
I have a custom module installed in Moodle (the certificate module). You can have the certificate emailed to the student. Currently, I have an ampersand in my course name and it's showing up as & amp ;. Here's what I mean:
The ampersand is showing in the email subject line and not getting encoded.
It is happening on gmail, and Mac mail. Any ideas on how to fix this or is this something that is out of my control?
You didn't post your HTML code, so it's difficult to see what might be happening.
An ampersand & next to another character might be interpreted as by the email client displaying the email as ASCII code, since the ampersand is used to display extended characters like the copyright symbol: © which can be displayed as: © or ©.
Extended characters are the characters that were not included in the standard ASCII character set. The original ASCII character set included all of the lowercase and uppercase letters on the keyboard (a, A), which are represented with ASCII codes 0 to 127. Anything above 127 is an extended character, for instance the Euro symbol, "€" € or the trade mark symbol "™" ™.
https://ascii-code.com
One thought is that your email is not being encoded in UTF-8, which allows you to use extended characters without much difficulty. Do you have something like this in the email head: <meta charset="utf-8">.
Good luck.
I just started using CK-editor as "Google HTML Editor" on HTML documents on my Google Drive.
I am noticing that all non-ASCII characters represented with HTML codes are being automatically shown as the actual character.
For example I use the following codes (I am putting spaces in the code, the editor is changing them to the actual character here, too!):
ç as & # 231 ;
Ç as & # 199 ;
Ö as & # 214 ;
etc.
CK editor changes these codes within the HTML source to Ç, ç and Ö immediately!
Is there a way to stop this?
We have developed Adobe air application that has option for Hindi and English. For translation we used microsoft office Hindi Pack and used on-screen keyboard to write in hindi. We have used Arial font in application.
In some of the client computers when language is changed to Hindi we see boxes in place of the words. The client computer is having Arial font available.
We are ready to embed the correct TTF file in our application but we are not sure which font file is being used by successful machines as we did not install any special font. Please help.
== Update===
Found there is an option to embed the font of the system application is compiled on. For that I used following code but it is not working:
[Embed(systemFont="arial", fontName="myArial",
mimeType="application/x-font", advancedAntiAliasing="true")]
protected var fontClass:Class;
and then in css file added
global
{
font-family: "myArial";
}
But I am getting errors:
Description Resource Path Location Type
exception `during transcoding: Cannot embed local font 'arial' as CFF. The CSS #font-face 'local()' syntax is not supported. Please specify a path directly to a font file using the 'url()' syntax. For [Embed] syntax the 'systemFont' attribute is not supported. Please specify a path directly to a font file using the 'source'` attribute. HondaLMS.mxml /HondaLMS/src line 81 Flex Problem
and
Description Resource Path Location Type
unable to build font 'myArial' HondaLMS.mxml /HondaLMS/src line 81 Flex Problem
I believe the systemFont name is "Arial", not "arial" (they are case sensitive).
If that does not work, try to embed it in css:
#font-face
{
src: local("Arial");
fontFamily: "myArial";
unicodeRange: U+0020-00FF; // change the range for your desired english and hindi characters, numbers and punctuation, otherwise you would embed ALL characters including cyrillic, chinese, arabic and whatnot and it would become huge
}
global
{
font-family: "myArial";
}
If it won't work with the font name reference, just copy the Arial font into your project directory and embed it with a relative path:
#font-face
{
src: url("../assets/Arial.ttf");
fontFamily: "myArial";
unicodeRange: U+0020-00FF; // change the range for your desired english and hindi characters, numbers and punctuation, otherwise you would embed ALL characters including cyrillic, chinese, arabic and whatnot and it would become huge
}
I have a JSON file with Greek names and letters ie.
{
"playerId":1,
"name":"Τ. Παπαγιάννης",
"position":"Τερματοφύλακας",
"age":"21",
"number":"15",
"photo":"/papagiannis.jpg",
"details":"Ακαδημίες ΑΕΛ"
}
I display this file on google chrome browser(through a local server called wamp) and it is a mess.
Is there any way to change that?
Thank you.
Theo.
FIXED
I used notepad++ then went to Encoding->Encode to UTF-8. That simple.
You should set the encoding to UTF-8
When I design a html page in Dreamweaver CS6 I use its validation tool (it sends the code to w3c) and I get no errors. However, when I validate the same page in UltraEdit 21 (it uses HTML Tidy) I get the warning:
"Specified input encoding (utf-8) does not match actual input encoding (utf-16)"
The page is set as html5 (with <!doctype html>), as utf-8 (with <meta charset="utf-8">) and contains greek text.
Well, the question is:
Does that problem affect the appearance of the page? I mean, when I publish it, will a user in China, Germany, or ...Tierra del Fuego see the greek text?
If yes, the rest are less important, but I'll ask them:
What makes HTML Tidy to define the document as utf-16? Is there a character, word or visible string of any kind that I can remove/delete to correct the problem?
If I use <meta charset="utf-16"> will browsers parse the code correctly (ending to greek text for the global user)?
The actual file encoding will be set in Dreamweaver properties for the file.
Dreamweaver Help / Set title and encoding properties for a page:
The Title/Encoding Page Properties options let you specify the document encoding type that is specific to the language used to author your web pages as well as specify which Unicode Normalization Form to use with that encoding type.
Select Modify > Page Properties, or click the Page Properties button in the text Property inspector.
Choose the Title/Encoding category and set the options.
...
Encoding
Specifies the encoding used for characters in the document.
If you select Unicode (UTF‑8) as the document encoding, entity encoding is not necessary because UTF‑8 can safely represent all characters. If you select another document encoding, entity encoding may be necessary to represent certain characters. For more information on character entities, see www.w3.org/TR/REC-html40/sgml/entities.html.
...
Include Unicode Signature (BOM)
Includes a Byte Order Mark (BOM) in the document. A BOM is 2 to 4 bytes at the beginning of a text file that identifies a file as Unicode, and if so, the byte order of the following bytes. Because UTF‑8 has no byte order, adding a UTF‑8 BOM is optional. For UTF‑16 and UTF‑32, it is required.
Choose UTF-8 without BOM.
UltraEdit automatically detects encoding of a file on opening and displays it at bottom in status bar. See in UltraEdit Advanced - Configuration - File Handling - Unicode/UTF-8 Detection and press button Help for some more details.
UTF-16 is displayed for a file encoded in UTF-16 Little Endian with or without BOM on using standard status bar since UE v19.00. Clicking on this list box in status bar and selecting Unicode - UTF-8 results in converting the file from UTF-16 LE to UTF-8 which then matches with the character set declaration in head of your HTML5 file.
When using basic status bar in UE v19.00 or any later version or using any UltraEdit version prior v19.00, the status bar field right to the field with line, column and clipboard number starts with U- for a file with UTF-16 LE encoding.
The UltraEdit help page about the Status Bar contains more information about information shown in standard and basic status bar in UltraEdit.
Conversion to UTF-8 can be done with UltraEdit also with command UNICODE/UTF-8 to UTF-8 (Unicode Editing) in submenu Conversions in menu File.
There are 2 configuration settings at Advanced - Configuration - File Handling - Save which define saving a UTF-8 encoded file with or without byte order mark (BOM):
Write UTF-8 BOM header to all UTF-8 files when saved
Write UTF-8 BOM on new files created within this program (if above is not set)
As UTF-8 encoded HTML files should be always without BOM, it is better to have both UTF-8 BOM settings unchecked when using UltraEdit mainly for editing HTML files.
Another possibility to convert a file with UltraEdit is using command Save As from menu File and use appropriate Encoding / Format setting. UTF-8 in Save As dialog means saving the file as UTF-8 encoded file with BOM and UTF-8 - NO BOM without BOM independent on the two configuration settings for standard Save.
For converting all files in a single folder, a folder tree, opened in UltraEdit, etc. to UTF-8 using UltraEdit, there is an UltraEdit scripting solution, see How to convert all files in a folder to UTF-8?
Unfortunately UE v21.30.0.1024 still does not recognize the short character set declaration <meta charset="utf-8"> as defined in HTML5 standard. See Short utf-8 charset declaration in HTML5 header with details about this limitation and how it can be worked around. This limitation does not matter if within first 64 KB at least one UTF-8 encoded character is found as it will be the case for your HTML5 files with Greek text.
HTML Tidy installed with UltraEdit v21.30.0.1024 is of version 25 March 2009. I'm not sure if HTML Tidy really supports short charset declaration of HTML5. But it looks so because otherwise you would not see the warning on validating the HTML5 file with HTML Tidy.
It might be useful for you to read UltraEdit power tip Unicode text and Unicode files in UltraEdit/UEStudio as it looks like you do not really know what encoding and character set really means and why it is important for applications that the declaration in the HTML5 matches with really used encoding.
I answer your questions now after all those general UltraEdit stuff.
Does that problem affect the appearance of the page?
Although the file contains the declaration that file contents is encoded with UTF-8, but is in real encoded with UTF-16 Little Endian, the browsers display the contents correct. UTF-16 detection is very easy, especially with BOM present and therefore browsers ignore wrong declaration and interpret the bytes of the HTML file from beginning right as UTF-16 encoded text file.
However, it would be much better to convert the UTF-16 encoded HTML files to UTF-8 without BOM. UTF-8 without BOM is most commonly used for HTML files worldwide and then the character set declaration in head of your HTML file would also match with really used encoding.
What makes HTML Tidy to define the document as utf-16?
The really used encoding of your HTML file is UTF-16 Little Endian and UltraEdit, HTML Tidy and the browsers detect that already after reading in the first 2 bytes of the text file - the byte order mark. That's the reason why HTML Tidy suggests to declare the encoding in head of HTML file correct as utf-16 as the file is really encoded with.
If I use <meta charset="utf-16"> will browsers parse the code correctly?
In case of keeping the file encoded in UTF-16 LE (always 2 bytes per character), it would be better to declare the character set right with <meta charset="utf-16">. But no Unicode aware text editor or browser has a problem to automatically detect UTF-16 Little Endian encoding with byte order mark.
The character set declaration becomes very important mainly for UTF-8 encoded files (1, 2, 3 or even 4 bytes per character) or files with single-byte coded characters using a code page like Windows-1252 / ISO 8859-1 (Latin 1) or Windows-1253 / ISO 8859-7 (Latin/Greek).