I'm trying to manipulate and modify a large number of eps files output by a web service. I have the code in python to interface with the server, and to edit the images to within about 99% of where I want them.
My issue deals with trying to display special characters. I've tried outputting the desired unicode character, Ψ, directly into the eps file, but this is displayed as different characters in both Preview for Mac and Adobe Illustrator. From some googling, it seems like eps doesn't accept unicode characters. Fair enough...
My current solution is to try to change the font in the eps files. This works when I want to display the Ψ as a single character. I just switch the font, and then switch back. As below:
/Symbol findfont 10.5 scalefont setfont
-9.1 36.1557 moveto (Y) show
/Helvetica-Bold findfont 10.5 scalefont setfont
Where I'm having a problem is when I want to display a title on each image. The title would include a mix of Helvetica-Light and Symbol fonts, I would want it to display as ABC1-Ψ123. I can't figure out how to switch the font of a single character within a larger block of text. Currently the eps files are written as shown:
/Helvetica-Light findfont 12 scalefont setfont
-43.093 304.224 moveto (ABC1-Y123) show
I'd appreciate any help.
Related
I'm rendering text with SkiaSharp for various platforms. I have problem with arabic script. I've created simple shaping routine and I have nicely connected glyphs. But diacritics is off completely.
Is there an easy way how to render/position diacritics? Like another table, which tells that after this char, put this glyph which represent diacritics in middle position, or something like that.
I'have tried HarfBuzzSharp, it's working ok, except Android (where it is returning zeros to all glyph positions).
I am just looking to get a better look for my iPad using custom font.
The default Arabic font for iOS8 devices is GeezaPro. and it's in .ttc format.
I am trying to replace it with my custom font.
I use DOSBOX to break system font ttc file into ttf files to make them editable.
Then i use FontLab Studio to replace system font glyphs with my custom font glyphs.
I just copy the glyph from custom font and paste them in the system font (using special paste option FontLab provide).
Then i use DOSBOX again to join these ttf files into ttc file.
That's worked for custom English fonts i used. but using it with arabic fonts show some issues.
The text letters appear separated in iOS apps and everywhere.(as you already know that Arabic language use joined letters and sometimes separated letters depending on the context. if the letter is the first letter it will use specific glyph, the same goes if the letter is in the middle or in the end using different glyph. while in English all letters are always remain separated no matter what. except for handwritten scripts.)
any idea how to fix?
some links:
tutorial I followed to port my fonts
the arabic font I am trying to accomplish (it's free and legit)
P.S: some may say use Bytafont library of fonts but i want to use this specific font. and arabic fonts also limited in the library (20 font only available).
Fonts are complex programs that run on embedded hardware interpreters and font engines (the same way game ROMs run on game hardware or in emulators), and don't just contain the pictures for each letter, but also all the instructions on how to position, combine, and substitute those letters based on what sequence of input it's being told to process.
For almost every font, just copying the glyph outlines is not enough, you also need to make sure that:
the original font's glyph ordering is preserved,
the GPOS table gets copied over (which determines mark positioning, kerning, etc), and
the GSUB table gets copied over (which handles glyph substitution, without which you can't even write Arabic. As an example, you need ـب, ـبـ, بـ or ب depending on context for the same "letter" bā’)
So you generally want to unpack the TTC (which as of OpenType 1.7 can be either truetype or postscript/type2, so that's a thing to remember for the future), then perform the replacements of glyphs (with order-preservation), as well as replacing the GPOS and GSUB tables (using FontForge or TTX) and then pack it back up into the TTC.
I am trying to place an overarrow over a piece of text in MathJax.
I am using a custom font that I declare in the code-
\(\overrightarrow{\style{font-family: mysans, TeX, Arial, sans-serif;}{\text{" + tString + "}}}\)"
It works ok for most letters- for capital W or M , using a couple in a row like "WWW" the overbar is too short.
For lowercase i , using a couple in a row, ie "iii" it is too long. My hunch is that MathJax is using a standard character width size to figure out the length of the overarrow and when the character is much longer or shorter than that size, it calculates the overarrow incorrectly. Is there any way around this?
Thanks!
First off, you generally cannot use custom fonts with MathJax. As the documentation says
Since browsers do not provide APIs to access font metrics, MathJax has to ship with the necessary font data; this font data is generated during development and cannot be generated on the fly. In addition, most fonts do not cover the relevant characters for mathematical layout. Finally, some fonts (e.g. Cambria Math) store important glyphs outside the Unicode range, making them inaccessible to JavaScript.
However, if you are only looking to use custom fonts in text elements, then there is a way to work around this: style the surrounding context and set mtextFontInherit:true for the output jax, cf. e.g. here for HTML-CSS.
Unfortunately, this won't actually help you right now. There's a minor regression in MathJax 2.5 (see this discussion leading to the result you describe). This will be fixed in 2.5.1 and in the mean time you could set noReflows:false for the HTML-CSS output.
Mathematica appears to have difficulty horizontally aligning accents (e.g. bars, hats, and tildes) when placed on top of certain mathematical symbols.
Here's a simple example:
Using the AdjustmentBox typesetting construct (or Alt-Left/Right arrow in the frontend), one can manually adjust the relative horizontal position of the hat and the symbol j to produce the more aesthetically pleasing:
There are two problems here:
1). It is inconvenient and time-consuming to make these manual adjustments when this should really be the job of the typesetting engine proper. Indeed, LaTeX is able to position accents correctly over all of the standard symbols (roman and greek letter forms) without the need to manually tweak their relative positioning.
2). The relative re-positioning of the symbols using AdjustmentBox is lost when exporting the Notebook to PDF for printing and re-distribution.
Question:
Does anyone have any suggestions for a more convenient way (preferably automatic) to improve the typeset quality of formulas in Mathematica notebooks that use accents, that preferably will also survive export of the notebook document to PDF format before printing?
You can select " ĵ " from the Windows character map and paste it in.
Style[ĵ, Italic, 24, Bold, FontFamily -> "Times"]
Also you can assign it to an input alias (borrowing from Andrew Moylan)
n = SelectedNotebook[];
SetOptions[n,
InputAliases ->
Append[Options[n, InputAliases][[1, 2]], "j^" -> "ĵ"]]
Typing Escj^Esc produces ĵ.
Well, I do not think that this is possible.
You may ask Wolfram Research to include unicode character 0135 , i.e., they should add \[JHat], like
\[IHat]. Then italics display nicely.
What was the original historical use of the vertical tab character (\v in the C language, ASCII 11)?
Did it ever have a key on a keyboard? How did someone generate it?
Is there any language or system still in use today where the vertical tab character does something interesting and useful?
Vertical tab was used to speed up printer vertical movement. Some printers used special tab belts with various tab spots. This helped align content on forms. VT to header space, fill in header, VT to body area, fill in lines, VT to form footer. Generally it was coded in the program as a character constant. From the keyboard, it would be CTRL-K.
I don't believe anyone would have a reason to use it any more. Most forms are generated in a printer control language like postscript.
#Talvi Wilson noted it used in python '\v'.
print("hello\vworld")
Output:
hello
world
The above output appears to result in the default vertical size being one line. I have tested with perl "\013" and the same output occurs. This could be used to do line feed without a carriage return on devices with convert linefeed to carriage-return + linefeed.
Microsoft Word uses VT as a line separator in order to distinguish it from the normal new line function, which is used as a paragraph separator.
In the medical industry, VT is used as the start of frame character in the MLLP/LLP/HLLP protocols that are used to frame HL-7 data, which has been a standard for medical exchange since the late 80s and is still in wide use.
It was used during the typewriter era to move down a page to the next vertical stop, typically spaced 6 lines apart (much the same way horizontal tabs move along a line by 8 characters).
In modern day settings, the vt is of very little, if any, significance.
The ASCII vertical tab (\x0B)is still used in some databases and file formats as a new line WITHIN a field. For example:
In the .mer file format to allow new lines within a data field,
FileMaker databases can use vertical tabs as a linefeed (see https://support.microsoft.com/en-gb/kb/59096).
I have found that the VT char is used in pptx text boxes at the end of each line shown in the box in oder to adjust the text to the size of the box.
It seems to be automatically generated by powerpoint (not introduced by the user) in order to move the text to the next line and fix the complete text block to the text box. In the example below, in the position of §:
"This is a text §
inside a text box"
A vertical tab was the opposite of a line feed i.e. it went upwards by one line. It had nothing to do with tab positions. If you want to prove this, try it on an RS232 terminal.
similar to R0byn's experience, i was experimenting with a Powerpoint slide presentation and dumped out the main body of text on the slide, finding that all the places where one would typically find carriage return (ASCII 13/0x0d/^M) or line feed/new line (ASCII 10/0x0a/^J) characters, it uses vertical tab (ASCII 11/0x0b/^K) instead, presumably for the exact reason that dan04 described above for Word: to serve as a "newline" while staying within the same paragraph. good question though as i totally thought this character would be as useless as a teletype terminal today.
I believe it's still being used, not sure exactly. There might be even a key combination of it.
As English is written Left to Right, Arabic Right to Left, there are languages in world that are also written top to bottom. In that case a vertical tab might be useful same as the horizontal tab is used for English text.
I tried searching, but couldn't find anything useful yet.