Re: [XeTeX] potential new feature: \XeTeXgenerateactualtext
Jonathan, is there any method in XeTeX to explicitly emit "ActualText" or override the automatic content generated by the new option? Or could you envision such a method? How would one need to approach it? (I'm not saying you should try implement it right away). :) A. Sent from my mobile phone. > On 23.02.2016, at 16:00, Jonathan Kew wrote: > >> On 23/2/16 14:52, Adam Twardoch (List) wrote: >> Jonathan, >> >> this is splendid. Adding support for the PDF "ActualText" tagging layer >> is a huge step. >> >> I wonder — what happens in case of mathematical formulae? > > At this point, nothing in particular. :) > >> I think it would be rather clever to embed the TeX notation or even, huh >> huh, MathML into the ActualText layer for the math mode — per equation, >> of course :) . > > I think these are ideas that could usefully be explored/implemented at the > macro level, rather than being built in to the engine. > > JK > > Or use the "Unicode math linear format" as proposed by >> Microsoft: >> http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf >> >> A. >> >> Sent from my mobile phone. >> >> On 23.02.2016, at 15:43, Jonathan Kew > <mailto:jfkth...@gmail.com>> wrote: >> >>> The code for the \XeTeXgenerateactualtext feature (it's an integer >>> parameter; set it to 1 to get ActualText added to the PDF, for better >>> copy/paste and search in Acrobat) is now on sourceforge, in an >>> "actualtext" branch, for anyone who wants to try building and >>> experimenting with it. >>> >>> Note that this requires a new version of xdvipdfmx, as it uses a new >>> DVI opcode. The patch for xdvipdfmx is attached here (based on the >>> current TeXLive svn source). >>> >>> Akira, if you could check that the patch seems OK, that would be >>> great. I've not really looked at dvipdfm-x code in a long time. I >>> haven't pushed this it to TL yet, as it's all rather experimental, but >>> I hope we can safely include it for TL'16. >>> >>> JK >>> >>> >>> >>> -- >>> Subscriptions, Archive, and List information, etc.: >>> http://tug.org/mailman/listinfo/xetex >> >> >> >> >> -- >> Subscriptions, Archive, and List information, etc.: >> http://tug.org/mailman/listinfo/xetex > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] potential new feature: \XeTeXgenerateactualtext
Jonathan, this is splendid. Adding support for the PDF "ActualText" tagging layer is a huge step. I wonder — what happens in case of mathematical formulae? I think it would be rather clever to embed the TeX notation or even, huh huh, MathML into the ActualText layer for the math mode — per equation, of course :) . Or use the "Unicode math linear format" as proposed by Microsoft: http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf A. Sent from my mobile phone. > On 23.02.2016, at 15:43, Jonathan Kew wrote: > > The code for the \XeTeXgenerateactualtext feature (it's an integer parameter; > set it to 1 to get ActualText added to the PDF, for better copy/paste and > search in Acrobat) is now on sourceforge, in an "actualtext" branch, for > anyone who wants to try building and experimenting with it. > > Note that this requires a new version of xdvipdfmx, as it uses a new DVI > opcode. The patch for xdvipdfmx is attached here (based on the current > TeXLive svn source). > > Akira, if you could check that the patch seems OK, that would be great. I've > not really looked at dvipdfm-x code in a long time. I haven't pushed this it > to TL yet, as it's all rather experimental, but I hope we can safely include > it for TL'16. > > JK > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] New feature planned for xetex
I think this is a phenomenal step. I don't think it's a specialized feature — it actually opens up a completely different usage field for XeTeX. The past treatment (single-word shaping) was making XeTeX difficult to deal with for purposes eg. of automated font testing or typesetting documents that used fonts that used contextual alternates across word boundaries, i.e. XeTeX's output in OpenType-intense usage fields has always been non-standard. This will make XeTeX more attractive for typographers who'd like to use XeTeX for shorter documents. :) Thank you, Jonathan! Adam Sent from my mobile phone. > On 18.02.2016, at 11:58, Jonathan Kew wrote: > > This is a pretty specialized feature, likely to be interest only to a small > minority of users. But for those it concerns, here's something that is > "coming soon to a XeTeX near you"... > > > I've recently implemented a new feature, controlled by the integer parameter > \XeTeXinterwordspaceshaping. This will be available in the TL'16 release, if > all goes well. > > This feature is relevant only when using OpenType/Graphite/AAT fonts, not > legacy .tfm-based fonts. > > When \XeTeXinterwordspaceshaping is greater than 0, XeTeX will attempt to > support fonts where the width of inter-word spaces may vary contextually, > depending on the preceding and following text. This is needed by fonts such > as SIL's Awami Nastaliq (in development) where words are expected to kern > together across spaces. > > The default behavior of xetex is to measure each word in isolation, and > simply string together a sequence of such word and space (glue) nodes to form > the horizontal list that is then line-broken to form a paragraph. Normally, > when inter-word spaces do not depend on the adjacent words, this works fine; > but in Awami the width of inter-word spaces may vary drastically, even > becoming negative in some cases. > > Setting \XeTeXinterwordspaceshaping=1 tells xetex to measure such spaces "in > context" and take account of the contextually-modified widths during line > breaking. This greatly improves the typeset result with such a font. Each > word is still shaped and rendered individually, but line-breaking and word > spacing respects the inter-word kerning. > > A further complication occurs when not only the width of the space but also > the glyphs of the adjacent words themselves may be subject to contextual > changes. An example of this would be a font that has OpenType ligature rules > that apply to multiple-word sequences; e.g. a symbol font that ligates the > text "credit card" to render a credit-card icon. Another example is the > word-final swash forms in Hoefler Italic, which are intended to be used at > end-of-line but NOT before word spaces within the line. > > These cases are addressed with \XeTeXinterwordspaceshaping=2. With this > value, not only are inter-word spaces measured in context, but also each run > of text (words and intervening spaces) in a single font will be re-shaped as > a unit at \shipout time. This allows full shaping (contextual swashes, > ligatures, etc) to take effect across inter-word spaces. > > Currently, this feature is implemented only in the "contextual-space" branch > of the code at sourceforge; anyone interested in testing it will need to > check out and build the code from there. After some time, if no major > problems show up, I expect to merge it to the master branch, and then to the > TeXLive source tree. > > Feedback welcome.. > > JK > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Using OpenType fonts of 2048 em-width glyphs with xelatex, using fontspec
There was a bug similar in nature in Mac OS X 10.10, which was fixed in 10.10.2: https://discussions.apple.com/message/27178893 Non-1000 UPM in CFF-based OpenType fonts is achieved by setting the UPM value in the font's 'head' table and setting a FontMatrix different from [1 0 0 1 0 0] in the font's 'CFF' table, so the CFF glyphs are actually "downsized" and that downsizing is then taken into account somewhere else. The bug in that OS X was in Apple's PDF module that the FontMatrix value was emitted (the downsizing happened) but in another place the original size was used. In your case, the opposite is happening. To me, it seems that the XeTeX PDF authoring driver is also emitting one part of the equation correctly but not the other. Only Apple's Preview is sensitive to that but I think it's still a XeTeX bug since XeTeX comes with its own PDF writer. Adam Sent from my mobile phone. > On 02.11.2015, at 10:19, Hugo Roy wrote: > > ↪ 2015-11-02 Mon 10:11, Adam Twardoch (List) : >> Are these fonts TrueType-flavored OpenType (.ttf), CFF-flavored OpenType >> (.otf), or some other format? > > > Sorry, I did not realise I forgot to mention this. It's a CFF OpenType font. > > > -- > Hugo Roy > ✆ +33608741341 > > Please use cryptography for email: see https://emailselfdefense.fsf.org/en/ > Merci d’utiliser la cryptographie pour l’email : voir > https://emailselfdefense.fsf.org/fr/ > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Using OpenType fonts of 2048 em-width glyphs with xelatex, using fontspec
Are these fonts TrueType-flavored OpenType (.ttf), CFF-flavored OpenType (.otf), or some other format? Sent from my mobile phone. > On 01.11.2015, at 20:41, Hugo Roy wrote: > > Hello everyone, > > I have been modifying an old font from the 1990s in order to be able > to use it with my setup, using XeTeX. > > Everything worked fine and I could produced PDFs, until I saw how they > were displayed by Mac OS’ Preview.app (see attachments for comparison). > > The issue is that the fonts are in a 2048 em-wide PostScript size > instead of 1000 (I sometimes get a warning from FontForge that the > width should be 1000). > > However, this does not seem to cause any problem for most PDF viewers > except Mac OS’ Preview.app and I am also able to get around the > problem with Preview.app by translating the PDF (1.5) to PostScript > and then back to PDF (1.4) again using ghostscript's ps2pdf. > > So I guess there must be a solution to use the fonts and produce PDF > that will work fine everywhere. > > > I have tried to convert the font from 2048 to 1000 automatically with > Fontforge, but the results aren't satisfactory (especially, the > BoldItalic font was too much messed up on the x-height of the glyphs > compared to the rest of the fonts in the family). > > At this point, I am not sure where to fix the problem, so I welcome > any expert opinion. If you think there are better places to ask for > opinions on this, I'm all ears. > > Please contact me directly if you want to test yourself with the > fonts, I can't share these fonts publicly. > > Thank you for your help, > > -- > Hugo Roy > ✆ +33608741341 > > Please use cryptography for email: see https://emailselfdefense.fsf.org/en/ > Merci d’utiliser la cryptographie pour l’email : voir > https://emailselfdefense.fsf.org/fr/ > > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Case changing for Greek
This type of selective assumptions is guaranteed to be error-prone. Greek is used not only in modern texts that are entirely in Greek language. Greek text can be surrounded with various types of punctuation. In particular, Greek words and phrases can be inserted into text written in other languages (eg. English) which then uses different punctuation conventions. So all kinds of punctuation, such as all types of quotation or question marks etc. and a full range of Unicode whitespace characters can legitimately follow a Greek phrase. A. Sent from my mobile phone. > On 07.05.2015, at 15:41, Joseph Wright > wrote: > >> On 07/05/2015 14:23, Nikos Platis wrote: >> 2015-05-07 15:22 GMT+03:00 Joseph Wright : >> >>> For performance reasons that code has been set up to assume that a >>> sigma is final if it is followed by a space, a control sequence or a >>> character from the list >>> >>>) ] } . : ; , ! ? ' " >> I would add to this list the dashes, "anoteleia", the greek closing quote >> "»". >> On the contrary, the english question mark "?" would not belong to a greek >> text. > > Thanks for the additions. Per Unicode, the final sigma rule applies to > all text using Greek chars, not just text in Greek, so a sentence in > English finishing with a Greek word should presumably apply the rule to > that word, hence having "?" in my list (I am aware that Greek uses ";" > to indicate a question). > -- > Joseph Wright > > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] (not) understanding XeTeXinterchartoks
In modern text processing (Unicode+OpenType), a text run is a series of
characters with the same formatting (font, size, color etc.), directionality
(ltr, rtl) and script (writing system such as Latin, Greek, Arabic or Gujarati).
A.
Sent from my mobile phone.
> On 08.05.2015, at 11:45, David Carlisle wrote:
>
> The following plain xetex document loops forever on \show\tmpb
> the \show don't cause the looping, if they are replaced by
> \def\zzzb{} xetex just hangs in a tight loop.
>
> The fact that it loops isn't necessarily a bug.
> \def\zzz{\zzz}\zzz
> does the same, but are there any words that could be added to
> the manual so that I could have predicted this?
>
> I'm not sure why 255 is being triggered at all as
> the X is being inserted into the middle of an existing hlist.
>
> The manual says 255 represents
>
>> a boundary between a `run' of characters and something else
>
> So I guess I am asking what 'run' means in this context:-)
>
>
>
> David
>
>
>
> \XeTeXinterchartokenstate = 1
>
> \newXeTeXintercharclass \Xclass
> \XeTeXcharclass `\X \Xclass
>
> \XeTeXinterchartoks 0 \Xclass = {\zza}
> \XeTeXinterchartoks 255 \Xclass = {\zzb}
>
>
> \def\zza{\futurelet\tmpa\zzza}
> \def\zzza{\show\tmpa}
>
> \def\zzb{\futurelet\tmpb\zzzb}
> \def\zzzb{\show\tmpb}
>
>
>
> xxxXxxx
>
>
> \bye
>
>
> --
> Subscriptions, Archive, and List information, etc.:
> http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Tex Gyre font project still around?
http://www.gust.org.pl/projects/e-foundry Sent from my mobile phone. > On 21.09.2014, at 08:44, Daniel Greenhoe wrote: > > What ever happened to the TeX Gyre font site at www.gust.org.pl ? It > doesn't seem to be alive anymore. Anyone know what happened to them? > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Will XeTeX or LuaTeX support COLR table in OpenType fonts?
On 13-08-30 15:01, William Adams wrote: Announced at the Microsoft //build conference: A data structure, implemented as a new 'COLR' table in OpenType, breaks down the base glyph into a separate set of glyphs, each with its own z-order and single color reference. The color references are handled has palette indices, with a separate table, 'CPAL' in OpenType that resolves the RGBA colors actually used for the glyph. Video here: http://channel9.msdn.com/Events/Build/2013/3-191 Original announcement on Typophile: http://typophile.com/node/104174 There is, in fact, a number of emerging technologies for multicolor font support. Currently, there are proposals from Apple, Google, Microsoft and Adobe/Mozilla on the table. Each proposal has its advantages and disadvantages, and aspects that distinguish them from the other proposals. I have summarized the proposals and provided an analysis here: http://typophile.com/node/105612 Regards, Adam Twardoch -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Latin Modern, from TFM to Unicode
Doug, if you think of the TFM slot indices as "glyph indices" rather than "character codes", then possibly, you can find a 1:1 mapping of all TFM indices to glyph IDs in the OTF. But not to Unicode codepoints. If your method of drawing glyphs on screen allows you to address glyph IDs directly (e.g. using FreeType or other such library which allows low-level addressing of glyph IDs within an OTF font file), then you should be able to achieve it. However -- I personally don't know which glyphs have this correspondence or whether the ones in the OTFs have the same repertoire or metrics. You'd probably be best to contact the GUST e-foundry project members directly: http://www.gust.org.pl/projects/e-foundry Unfortunately, apart from http://www.gust.org.pl/contact-info I don't see any easy way to contact them using public channels. Regards, Adam On 13-06-12 21:32, Doug McKenna wrote: Thanks for all the responses. I understand the distinction between Unicode characters (code points) and glyphs, and that an OpenType font can have glyphs in it that do not correspond to any Unicode code points. I don't quite get whether or how those non-Unicode glyphs are subject to being found via the 'cmap' table, or whether they have glyph IDs that are known or can be determined by some documented convention outside the OpenType font file. Or whether they are part of some internal ligature-like structure that only the OpenType font has information about (which might mean that the glyph IDs can change internally from one release to the next of the OT font). Arthur Reutenauer responded: These glyphs or parts of glyphs can probably be mapped one-to-one to font slots in the original lmex10, but that does not make them characters. Understood about not being characters. But it's that one-to-one mapping from each slot in TFM to an equivalent slot in OpenType (for Latin Modern) I'm interested in pinning down (hopefully not "probably"). It certainly appears that every glyph represented by "lmex10.tfm" can be found in the "Latin Modern Math" font file, though I haven't gone through all 128 trying to find where they appear in the OT font. Khaled Hosny wrote: [snip numerous good explanations] Thanks. I understand better what's going on inside the OpenType font, and can now imagine how FontBook is figuring out which glyphs are not the targets of the 'cmap' table's Unicode code point inputs. And I understand that the math extension font contains glyphs for different sizes of the same symbol, but kept in different slots with different glyph indices (if that's the right term) in the TFM file. I"m not sure what do you want to achieve, and you might be asking the wrong question, so it might be better to elaborate more on your actual goal. I have my own homebrew math layout system that determines where to place math glyphs based on information in the lmex10.tfm and other TFM files. For reasons peculiar to my needs, I'm not interested in creating PDF or DVI output. I just want to draw a math glyph on my screen using "Latin Modern Math" at a computed position, based on where TeX would place it using the metrics in "lmex10.tfm" or other TFM file (the extent to which I'm accurately simulating TeX is a side-issue, but I'm trying hard). My assumption was that the glyphs in the OT file are the visually the same, and have the same metrics/bounding boxes, etc. as the original TFM metrics. Or if they don't have quite the same metrics, the differences are not going to change over time with new versions of the OT font. I assumed that every one of the 128 glyphs represented by slots in lmex10.tfm would be found in the OpenType font "Latin Modern Math", along with lots of other glyphs. I had thought that all the glyphs in the OT font had Unicode character designations, but have now understood that that is not a good assumption. Consider the radical sign. In the TFM file, there is information that TeX uses to determine which final glyph(s) to use, based on the height of the box of whatever's underneath the radical. So TeX chooses the glyph in slot "70 for small height, or the glyph in slot "71 for medium height, or the one in slot "72 for large height, or slot "73 for even larger height. If none of those fixed-height glyphs are high enough, presumably TeX goes into a tall symbol construction algorithm based on data within the TFM file, using glyphs representing pieces of radical signs, kept in slots "74, "75, and "76. Using FontBook, in the "Latin Modern" OpenType file, the glyph for the official Unicode code point U+221A SQUARE ROOT is glyph ID #2839. So that's a "character" I suppose. The 'cmap' table maps that Unicode value to that glyph ID and it can be drawn as a character would. But there are also non-Unicode glyphs for partial radical signs, all of which look identical to the glyphs shown by /fonttable for "lmex10.tfm" (which are taken from some PFB file). In particular, I've figured out by inspecti
Re: [XeTeX] PDF V1.6 too recent
On 13-01-10 16:23, Philip TAYLOR wrote: > My Adobe Acrobat Professional is dated 2006; > My XeTeX is dated 2011. > > Why does my 2011 XeTeX tell me that the PDF version > generated by my 2006 Adobe Acrobat Professional is too recent ? > >> > ** WARNING ** Version of PDF file (1.6) is newer than version limit >> > specification. Philip, It this case, "recent" means "too high a version". Adobe has kept adding "fancy" features to the PDF spec since version 1.3 or 1.4, which are not print-related, such as JavaScript, embedded Flash, forms etc. Many non-Adobe PDF interpreters or parses only support the older PDF versions. I'm not sure which is the highest version of PDF that XeTeX supports, but my guess it'd be 1.3 or 1.4. But that's also a popular practice by some print publishers. Recently I had to submit a print ad to a magazine, and their requirement was that it should be PDF version no higher than 1.4. Best, Adam -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Access of vertical CJK fonts preceeding with @
On 12-12-07 09:23, Gerrit wrote: > The problem is that many Japanese word processors rely on Japanese > encodings, not on Unicode. Looks like upTeX supports Unicode: http://homepage3.nifty.com/ttk/comp/tex/uptex_en.html A. -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Access of vertical CJK fonts preceeding with @
I think proper vertical writing mode would be best, without resorting to multiple rotations :) Yes, the "vert" is used for punctuation but also for Latin glyphs, which are often proportional in "height" (ie. avtually "rotated width"). "vert" is typically used in combination with "vkrn", which then does vertical kerning. So if toy have the text "Typeface" set in a CJK font vertically, the "vert" feature would map the glyphs T, y, p, o, g etc. to their counterparts which are rotated by 90 deg to the right, and then the "vkrn" feature would move the rotated "y" up if following a rotated "T" -- by the same amount as the normal "Ty" kerning pair. Of course not all CJK fonts include rotated Latin glyphs, let alone proportional, and let alone with vertical kerning. But some do (especially Adobe's Japanese fonts). There is another set of features (fwid, pwid, hwid -- AFAIR) which switch Latin glyphs and punctuation between full-width (monospaced), proportional (normal from the European perspective) and half-width (narrow monospaced) variants. Using them is up to the user's preference and discretion. Some but not all fonts provide rotated forms for all these variants as well. But all this stuff is made to work with the "true" vertical typesetting direction in mind, and has to do with things that happen within the line. Stuff that happens on the higher level, i.e. by which means you actually get entire lines to be laid out in the vertical direction, is a wholly another level. As I mentioned, the "@" hack is just a Windows API trick -- these special fonts don't really exist, they're being synthetically generated by the Windows API and are exposed to apps that use the Windows API to do text layout and rendering. But XeTeX accesses font files more directly, and directly parses OpenType Layout tables, so the "@" trick shouldn't work since these are not "real" fonts. And, as I said at the beginning, I think proper vertical writing mode in XeTeX would be the *real* solution, without resorting to OS API tricks. However, I'm not at all a TeX expert so I don't know which options are available. Best, Adam Sent from my mobile phone. On 07.12.2012, at 00:03, Gerrit wrote: > Hello Adam, > > thanks for you answer. I didn’t know that the @ thing is a Windows feature. > Well then I guess it does not work. > > I just wondered if it might be an easy and actually good way to create > vertical Japanese texts (not just a paragraph or a text box, but the entire > document): Everything like columns, page break, sections etc. would work > flawlessly . Incorporating Western text in the text would also work without > any problems. > > Basically I just thought about using the @ font, rotating the entire page 90° > clockwise (so that the text is vertically and the alignment is correct), > flipping the width and height size of the paper, so that a portrait paper > stays a portrait paper, and then the text would work. > Horizontally written picture boxes/captions or tables etc. could be done with > the normal rotating package (i.e., rotating them back). The only problem > would maybe be the head and foot, because the rotated page would then have > the head and foot on the right and left side, resp. But I thought about > tackling that issue afterwords. Either way, I just wanted to try it out. > > Rotating every glyph independently (like it is done in the xetex manual) does > not seem to be that suitable for longer texts, and you would have to cope > with many many many packages and other problems. > > As far as I understood the vert feature, it works for rotating stuff like the > colon (ten), the full stop (maru), brackets etc. A normal character would not > have to be rotated. This is then necessary if you actually do it for rotating > every single glyph, but not if the entire text becomes rotated and you > basically just rotate the page backwards. > > I actually really think that something like the @ thing would be the easiest > way to implement vertical typeset into Xetex. > > Gerrit > > Am 06.12.2012 23:48, schrieb Adam Twardoch (List): >> Gerrit, >> >> this is a custom functionality of the Windows API, a "poor man's" method to >> get vertical typesetting in "normal" applications which cannot deal with >> real vertical typesetting. The "vert" feature is different: it provides >> additional 90 degree rotation for those glyphs which are read better in a >> horizontal arrangement rotated by 90 degrees. I.e. you use the "vert" >> feature in a *real* vertcal typesetting context where
Re: [XeTeX] Access of vertical CJK fonts preceeding with @
Gerrit,
this is a custom functionality of the Windows API, a "poor man's" method to get
vertical typesetting in "normal" applications which cannot deal with real
vertical typesetting. The "vert" feature is different: it provides additional
90 degree rotation for those glyphs which are read better in a horizontal
arrangement rotated by 90 degrees. I.e. you use the "vert" feature in a *real*
vertcal typesetting context where CJK glyphs occur one under the other, but
e.g. for Latin glyphs it makes sense to set them so that the reader has to turn
his head to the right.
So "vert" is completely independent of what you're asking. If XeTeX cannot do
"proper" vertical typesetting then perhaps indeed there should be a font
selection function that just rotates everything set in that font. I'd rather
have such a mechanism exposed than to rely on a non-cross-platform "@" prefix
"OS hack" (a hack actually provided by the OS). I don't know whether such
mechanism already exists in XeTeX though. Perhaps it does?
Either way, you'd still want to apply the "vert" feature to do additional 90
degree rotation for certain glyphs, or -- if used in the scenario you're
proposing -- to actually *un-rotate* them, so they bacome horizontal again.
A.
Sent from my mobile phone.
On 06.12.2012, at 22:59, Pander wrote:
> On 2012-12-06 20:59, Gerrit wrote:
>> Hello,
>>
>> Every (or most) Japanese/Chinese font has a version where everything is
>> rotated 90 degrees.
>> For example, MS Mincho has a @MS Mincho version.
>> If you select that font, you would just have to turn the page by 90° and
>> you get a correctly vertically set text.
>>
>> My most basic example is this:
>>
>> \documentclass{scrartcl}
>> \usepackage{fontspec}
>> \setmainfont{MS PMincho}
>> \begin{document}
>> 日本語
>> \end{document}
>>
>> This works. If I use \setmainfont{@MS PMincho} though, I get many many
>> errors (482 to be exact).
>> Is there a way to access the font? Is this maybe because the font is
>> somehow hidden (You can't see them normally, but e.g. Wordpad shows them).
>> Or should I use an Opentype feature instead? I guess that would be
>> cleaner, but is there a feature to rotate everything? For me it seems
>> that the vert feature etc. only changes some glyphs, and not all of them.
>
> Once I made an overview document of about 160 Japanese fonts, the
> punctuation characters they support and their ability to rotate properly.
>
> If you want I can send you the PDF in a personal message. This is still
> a document in development. If people are interested in collaborating on
> this to finalise it, please let me know too.
>
>> Thank you!
>> Gerrit
>>
>>
>> --
>> Subscriptions, Archive, and List information, etc.:
>> http://tug.org/mailman/listinfo/xetex
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
> http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Nastaliq [was: The future of XeTeX]
I didnot say it's Nastaleeq-specific, or exclusive to Nastaleeq. But Nastaleeq is possibly the most relevant script variant that heavily relies on cursive attachment in OpenType. Sent from my mobile phone. On 02.08.2012, at 10:53, Khaled Hosny wrote: > But that is not Nastaliq specific (Arabic Typesetting uses cursive > attachments extensively too, my Naskh font uses them occasionally as > well). So, any sufficiently complex font will have issues with such > engines, Nastaliq or not. > > Regards, > Khaled > > On Thu, Aug 02, 2012 at 04:40:55AM +0200, Adam Twardoch (List) wrote: >> Nastaliq OpenType fonts typically use the GPOS LookupType 3 (cursive >> attachment), which is not supported by some of the more simple-minded >> OpenType Layout engines. >> >> A. >> >> Sent from my mobile phone. >> >> On 02.08.2012, at 04:28, Mike Maxwell wrote: >> >>> On 8/1/2012 6:48 PM, Khaled Hosny wrote: >>>> I remember specifically testing some Nastaliq fonts and Hans fixing some >>>> small issues I found, I just tested again now and IranNastaliq seems to >>>> work (my fork of Nafees Nastaleeq is broken though, but it uses an >>>> OpenType GDEF feature not supported by LuaTeX's font loader, so this is >>>> expected and not even Arabic specific). >>> >>> I'm interested in this. We have used Nafees Nastaleeq v1.2 (IIRC), and >>> plan to use it for Punjabi written in Shahmukhi. While this font works >>> reasonably well in XeTeX, there were a couple things we were bothered by. >>> But it's been awhile since we last used it, and we're not experts in this >>> style of Arabic script, so I can't remember the problems, nor would I be >>> confident enough to say much about them anyway. >>> >>> Have you written up your work on Nastaliq? >>> -- >>> Mike Maxwell >>> maxw...@umiacs.umd.edu >>> "My definition of an interesting universe is >>> one that has the capacity to study itself." >>> --Stephen Eastmond >>> >>> >>> -- >>> Subscriptions, Archive, and List information, etc.: >>> http://tug.org/mailman/listinfo/xetex >> >> >> >> -- >> Subscriptions, Archive, and List information, etc.: >> http://tug.org/mailman/listinfo/xetex > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Nastaliq [was: The future of XeTeX]
Nastaliq OpenType fonts typically use the GPOS LookupType 3 (cursive attachment), which is not supported by some of the more simple-minded OpenType Layout engines. A. Sent from my mobile phone. On 02.08.2012, at 04:28, Mike Maxwell wrote: > On 8/1/2012 6:48 PM, Khaled Hosny wrote: >> I remember specifically testing some Nastaliq fonts and Hans fixing some >> small issues I found, I just tested again now and IranNastaliq seems to >> work (my fork of Nafees Nastaleeq is broken though, but it uses an >> OpenType GDEF feature not supported by LuaTeX's font loader, so this is >> expected and not even Arabic specific). > > I'm interested in this. We have used Nafees Nastaleeq v1.2 (IIRC), and plan > to use it for Punjabi written in Shahmukhi. While this font works reasonably > well in XeTeX, there were a couple things we were bothered by. But it's been > awhile since we last used it, and we're not experts in this style of Arabic > script, so I can't remember the problems, nor would I be confident enough to > say much about them anyway. > > Have you written up your work on Nastaliq? > -- >Mike Maxwell >maxw...@umiacs.umd.edu >"My definition of an interesting universe is >one that has the capacity to study itself." >--Stephen Eastmond > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
> Martin Schröder wrote: >> And JS isn't designed for embedding Interesting. I must admit that so far, I've *only* used JavaScript as an embedded language -- starting with every web browser, plus most Adobe applications, OpenOffice, as well pretty much all of Microsoft Office applications (through Active Scripting). There is a quite large number of JavaScript VMs available, and as far as I can tell, all of them were specifically developed with embedding in mind. A. -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On 31.07.2012, at 13:02, Peter Dyballa wrote: > it's questionable whether it's worth when XeTeX has reached its end of life > cycle and LuaTeX is taking over – without micro-typography that seemed to > have started in ConTeXt… I don't think this is an accurate description of the situation. In my opinion: 1. XeTeX is a more encapsulated, "pragmatic" system that may not be endlessly extensible and may not be suitable for arbitrarily complex projects, but it's simple to use (hey, even I can use it), is very much feature-complete in what it's supposed to do, and is very stable. For 80-90% of TeX use cases, it's the perfect system. Conceptually, it's very much like an Apple product: it does the things that it claims it does rather well, and simply doesn't do many things, but doesn't claim to do them. It's also very reasonably documented. 2. LuaTeX is more a "project" than a "product". Potentially, it's extremely extensible and can potentially do things that no other system practically can. But it doesn't (by its very nature) offer stability, it's evolving constantly, and while some features it claims to offer are at a "version 1.0" level, others are at a "version 0.2" level — and if you're not careful, you may not easily distinguish these. It's idealistic, ambitious but also complex. If you just need a practical tool that works and don't want to get into a developer's mind, XeTeX is a great choice. If you're creative and experimental, and want to do new things that were never attempted before, LuaTeX may be better. If LuaTeX was PythonTeX, I'd adopt it instantly. IMO, Lua was a very unfortunate choice, which seriously limits the potential usefulness, but let's leave it at that. Adam -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On 12-07-31 11:34, Jonathan Kew wrote: > ...of misinformation, I'm afraid. Indeed. Keith J. Schultz wrote: >> Let us take ATSUI. Why has Apple abandon it? Well, I do not believe >> there are are any native ATT-fonts in the MacOS X any more. Most complex-script fonts (Arabic, Indic etc.) that ship with Mac OS X are AAT, and continue to be. In fact, Apple is actively developing AAT: Mac OS X 10.8 Mountain Lion has support for a new "kerx" table which allows for horizontal and vertical class-based kerning, much akin to the OpenType Layout GPOS table. AAT is also actively supported on iOS, especially for performance issues (the layout of AAT complex-script fonts is approx. 3x faster than of OTL fonts with comparable functionality). >> >> Is Core Text a alternative? Not, actually. > > Yes, actually. Core Text is the modern, supported replacement for > ATSUI functionality. AAT is Apple's layout technology. ATSUI and CoreText are different APIs. Similarly, OpenType Layout is another technology. Analogically, HarfBuzz and Pango are two different APIs for that. > Core Text doesn't have "support for ATSUI" in the sense of providing a > set of ATSUI-clone APIs to applications, but it most certainly does > have support for AAT fonts, which is the relevant issue here. True. One aspect of AAT that CoreText may have dropped (but ATSUI still has) is TrueType variations (fvar/gvar table) -- though I'm not entirely certain of it. But, as mentioned above, AAT is being actively developed, contrary to what you may believe. Regards, Adam -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On 12-07-30 23:40, Philip TAYLOR wrote: > OK, thank you Adam. I think perhaps I was being unrealistic in > asking whether the two PDFs would be visually identical; for the > very reasons you adduce, it is clear that this can never be the > case. But differences at the syntactic level are a far greater > concern : I think one should accept that if one passes an extant > XeTeX source through LuaTeX, line and page breaks may well differ, > but if LuaTeX barfs on valid XeTeX source, that is (for me, at > least) a far greater concern (and a reason against adoption, to > be honest). I believe that the TeX world needs a "policy" on naming engine-specific commands. This is akin to the CSS browser-specific prefixes, such as "-webkit-text-security" or "-moz-font-features". XeTeX already does this: all the XeTeX-specific commands are prefixed with "XeTeX". Some of those commands are of general use (in such case, the XeTeX and LuaTeX developers should communicate to standardize a new command) while others may really not be of general use at all, as they're more-less "hacks" or ways to achieve certain effects in a way tied very much to the specific implementation of the engine. For example, there is the XeTeX command: \XeTeXfonttype ‹font› Expands to a number corresponding to which renderer is used for a ‹font›: 0 for TEX (a legacy TFM-based font); 1 for ATSUI (usually an AAT font); 2 for ICU (an OpenType font); 3 for Graphite. which really is very much tied to how XeTeX works. *** BTW: HarfBuzz has several backends, so if it gets integrated into XeTeX, I'd advise reserving several numbers for it, e.g.: 4 for HarfBuzz native OTL 5 for HarfBuzz Uniscribe 6 for HarfBuzz Graphite *** Many other XeTeX commands such as \XeTeXfindselectorbyname also only make sense in the XeTeX environment. However, I'd say -- perhaps the LuaTeX developers could create a special "stub xetex" macro package which reimplements the XeTeX-native commands as macros that follow the same syntax as XeTeX. Many of those macros would not necessarily need to "work" i.e. do anything effectively -- but at least they would be ignored gracefully rather than failing. But I don't really know whether this is a good idea -- my knowledge of "good practices in TeX" is close to null :) As you know, I'm not really a "TeX person", i.e. I try to follow the developments but don't participate actively or use TeX. Regards, Adam -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Phil, I cannot comment on how 100% compatible LuaTeX and XeTeX are when it comes to the "core" set of TeX language and when only TeX-native fonts are used. It's possible they are 100% compatible, or that they're not -- I don't know much about this. However: * XeTeX has several commands that were introduced in pdfTeX and are native to LuaTeX, and XeTeX reimplements them in a way that I believe is compatible. These commands include \pdfpageheight, \pdfpagewidth, \pdfsavepos and some others. * XeTeX has some commands that are native to XeTeX only such as \XeTeXpicfile, \XeTeXpdffile, \XeTeXmathaccent, \XeTeXvariation, \XeTeXOTfeaturetag, \XeTeXuseglyphmetrics, \XeTeXglyph and some others. You can use them in XeTeX but not in LuaTeX * I presume LuaTeX also has some commands or syntax aspects (esp. the injected Lua code) that will run in LuaTeX but not XeTeX * Even with the same core set of commands, if using OpenType fonts, the results between LuaTeX and XeTeX will necessarily vary. LuaTeX and XeTeX use different mechanisms when it comes to extracting glyph metrics, kerning, other positioning commands, and also different mechanisms when it comes to processing things like OpenType contextual alternates etc. -- and by using different mechanisms, it by necessity arrives at results that differ slightly. No known OpenType Layout engine out there (Microsoft Uniscribe, Monotype WorldType, Bitstream Panorama, Adobe World composer, ICU Layout, HarfBuzz, Pango, or the LuaTeX engine) is 100% compatible with any other, so the same line, or even word, may be typeset slightly differently with each of those layout engines. This will, in the end, necessarily result in different glyphs being used at times, different line-breaking being generated etc. When it comes to Unicode and OpenType, it's much more complex than the original 8-bit Western world, and cross-platform compatibility is no longer a goal that can be achieved at this time. I'd say the situation is similar to the world of web browsers: HTML, CSS and JavaScript are being actively developed, but some snapshots of the development are strictly documented by the W3C, yet other factors come into play so that a 100% pixel compatibility between Mozilla Firefox, WebKit (Chrome or Safari), Microsoft Internet Explorer and Opera is not achievable, and probably never will be. Regards, Adam On 12-07-30 23:12, Philip TAYLOR wrote: > > > Zdenek Wagner wrote: > >> If only Unicode support and access to system fonts are concerned, a >> replacement already exists, namely luatex. > > I have held back from experimenting with LuaTeX because I have > been led to believe, from this list and elsewhere, that LuaTeX > and XeTeX are not in 1:1 correspondence in terms of the syntax > and semantics of some non-Lua-related features. Are you able > to comment on this from a position of knowledge ? Or, from the > converse perspective, would you be able to assure me and others > that all extant XeTeX code will execute in LuaTeX without error > and produce a PDF that is visually indistinguishable from the > PDF that XeTeX would produce using the same source ? > > Philip Taylor > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On 12-07-30 21:00, Zdenek Wagner wrote: >> The question is: is it >> easier to find a volunteer for maintaining XeTeX or a volunteer who >> will implement missing features for luaotfload and port important >> packages as Polyglossia to luatex? It is definitely easier to replace the ICU Layout integration in XeTeX with HarfBuzz integration, and to tweak the XeTeX code to potentially remove the native Mac OS X font engine integration (or at least make it optional) than to write full-scale OpenType Layout shapers in Lua from scratch. HarfBuzz is still not perfect but it definitely developing towards becoming the only sensible OpenType Layout engine within the open-source realm. Developing some of the shapers, especially for Indic languages, is not trivial per se (it is taking the HarfBuzz developers quite a long time, and it is after all an intensive effort). Doing everything from scratch in Lua will be a similarly long-winded effort: Lua is not a very popular language, and even if an complete OTL solution is created in Lua some day, it will need maintenance. The great thing about the XeTeX concept is that it doesn't try to do everything itself. It uses the best available components to do the heavy-lifting. When Jonathan Kew created it, ICU Layout was the best OpenType Layout library available. Soon, HarfBuzz will be the best one, guaranteed to be maintained. As I've written on this list previously, integrating HarfBuzz into XeTeX (as an alternative to the existing engines, i.e. ICU Layout, Graphite 1 and ATSUI) would be very desirable. I think such a project could be funded by some of the existing TeX groups. Best, Adam -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] openType and xetex
Youcef is right: AFIR, XeTeX supports three layout engines: * ICU Layout, cross platform, working with OT Layout tables in SFNT fonts * Graphite, cross-platform, working with Graphite tables in SFNT fonts * ATT, Mac OS X only, working with OT Layout tables and AAT tables in SFNT fonts. I don't remember whether XeTeX in addition also supports Uniscribe on Windows. Given the fact that XeTeX is already set up to handle multiple layout engines, it would be relatively easy to add support for more -- especially to add support for Harfbuzz. I would applaud if anyone volunteered to do that (Harfbuzz has sample code that shows you how). It'd be particularly neat since Harfbuzz itself also supports several backends, in particular it supports Uniscribe on Windows. So if XeTeX does not currently support Uniscribe, adding Harfbuzz support would also cheaply add Uniscribe support. Harfbuzz also has Graphite2 support so the old direct Graphite support in XeTeX could be replaced or complemented with Harfbuzz+Graphite2. XeTeX would be seriously improved if Harfbuzz support were added. Best, Adam Sent from my mobile phone. On 28.06.2012, at 17:50, Khaled Hosny wrote: > I suspect it might be the same issue. > > Regards, > Khaled > > On Thu, Jun 28, 2012 at 05:00:26PM +0200, Dominik Wujastyk wrote: >> Khaled, >> >> Is this the same problem that Zdenek and I have been discussing recently in >> relation to ligatures in the Devanagari script? I.e., the ICU from 2009 >> worked >> fine, but subsequent releases didn't? >> >> Dominik >> >> >> >> On 28 June 2012 16:27, Khaled Hosny wrote: >> >>On Thu, Jun 28, 2012 at 10:10:56AM +0100, Youcef Mohammed wrote: >>> (...)fast quik rapid >>> Windows is not Apple!!! >>> The font in question is not Graphite font...!!! >>> (serious) >>> -it seem that the problem is with the "mkmk" (mark-to-mark) >>positionning... >> >>No, mkmk is working fine, but there is a problem with contextual >>chaining substitution lookups, it have been buggy for years and there is >>a ICU bug ticket for it, but I can't find it right now. >> >>Regards, >> Khaled >> >> >>-- >>Subscriptions, Archive, and List information, etc.: >> http://tug.org/mailman/listinfo/xetex >> >> > >> >> >> -- >> Subscriptions, Archive, and List information, etc.: >> http://tug.org/mailman/listinfo/xetex > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Typesetting Greek mathematical text using Unicode
My Cambria is "Version 5.96", "© 2009 Microsoft Corporation. All Rights Reserved." A. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] TeX in the modern World. (goes OT) Was: Re: Whitespace in input
> Yet, it remains one of the most > powerful and cheapest typesetting systems to date. "Cheap" in terms of initial investment -- surely, as it's open-source and free. "Cheap" in terms of implementing -- not quite so, because you need to format your sources in a very specific, "isolated" syntax. I initially tried to implement TeX in some projects of my own, and switched to Prince XML (http://princexml.com/ ) I found it much easier to start with, as it takes HTML or XML + Unicode + CSS + SVG/bitmaps + OpenType fonts as input, executes JavaScript during processing, has a rather high-quality, constantly improving line-breaking algorithm, and produces reliable PDFs. Some aspects of it are not quite as powerful as TeX's, but other aspects greatly surpass TeX -- especially in terms of ease of use and quick implementation while maintaining acceptably high quality. So I ended up with Prince XML as my tool of choice because it natively supports my "preferred input formats", i.e. the web formats. A commercial server license costs 3800 USD, which may sound like a lot, but I found it a fair price to pay for the comfort of being able to use my content directly and without much debugging/converting/fine-tuning. Best, Adam -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Printing OTF glyph features
Stephan, you can print font glyphs in XeTeX using \XeTeXglyph followed by the glyph's decimal index. You'd need to use a different tool to do the parsing of the OpenType Layout tables, though. The Python package FontTools/TTX or FontForge compiled as a Python module can be used to extract this information. You'd need to do some coding though, going through the GSUB lookups and compile a list of glyphs that are being output. A. On 11-11-15 06:46, Stephan wrote: > Good day, > > I have been trying to print out the glyphs of a font (in my case Minion) that > are used in a stylistic variant. But I have not been able to do that... > > Is there a way of printing, let's say, all the glyphs that would be used if a > feature in a font is turned on ? > > For example, the "k" in this stylistic variant is different from the regular > "k" in the Minion font, however, I would like to know what other glyphs may > be > affected. > > Thanks, > > -Stephan > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- May success attend your efforts, -- Adam Twardoch (Remove "list." from e-mail address to contact me directly.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] kpathsea: Invalid fontname `[/Library/Fonts/MyriadPro-Cond', contains '['
My code is:
%!TEX TS-program = xelatex
%!TEX encoding = UTF-8
\documentclass{minimal}
\usepackage[margin=40pt, paperwidth=1024bp, paperheight=768bp]{geometry}
\usepackage{fp}
\usepackage{parskip}
\pagestyle{empty}
\newlength{\testlength}
\newlength{\testfontsize}
\newlength{\linesp}
\setlength{\linesp}{10pt}
\makeatletter
\newcommand{\linetowidth}[2]{%
\setlength{\testfontsize}{10pt}%
\font\samplefont=[#1] at \testfontsize%
\samplefont%
\settowidth{\testlength}{#2}%
\typeout{\the\testlength}%
#2\par%
}
\makeatother
\begin{document}
\openup \linesp
\XeTeXuseglyphmetrics=1
\def \fontfolder{/Library/Fonts}
\linetowidth{\fontfolder/MyriadPro-Cond.otf}{Medical split}%
\end{document}
%%
I'm successfully getting a PDF output but I'm getting the following
error in the console:
kpathsea: Invalid fontname `[/Library/Fonts/MyriadPro-Cond', contains '['
Any hints?
Best,
Adam
--
May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Proper way to set up OT Features
The OpenType Layout mechanism is based on "glyph runs". First, the text engine separates a line into glyph runs, and then applies features to each run as if it were separate (i.e. there cannot be any feature interaction between the runs). The tricky part is that every layout engine has a different mechanism for separating the line into the runs. Of course a switch of the font, or font size, always defines a run boundary. Most layout engines treat the change of text directionality as a glyph run boundary. But they all may differ in how they process characters that do not have a strong directionality. So if you mix Arabic and English, and put a period or a number between a portion of English and Arabic text, different layout engines may classify the period or a number as belonging to one or the other of the adjacent runs, or even to a separate run. Same happens with other punctuation characters. If you type in an Arabic letter, a slash (/) and an English letter, and if the font has GPOS kerning pairs defined between the Arabic letter and the slash, and between the slash and the English letter, either one of those pairs or even both will not work. In addition -- and here the difference is even larger -- layout engines treat the space character very differently. Some applications add an extra space glyph at the end of the line (for example InDesign), so certain contextual rules won't work. Some do and some don't render the space glyph that is used in the font. For example, XeTeX doesn't. If the space glyph is non-blank, it will render in Word but not in XeTeX. In other words, XeTeX puts a run boundary at the beginning and the end of each word, so no OpenType Layout lookups that involve the space glyph will work. Best, Adam -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Proper way to set up OT Features
I'd recommend checking the features in raw mode (typing from memory, please
double check the syntax):
\font\cardofont="[/Users/David/Desktop/Cardo-Regular.otf]:+liga,+dlig,+hlig" at
12pt
\cardofont
ghostly firefly acts strange
By accessing the font file directly using it's path, and specifying the
features using their OT Layout feature tags, you'll be able to tell if it's a
fontspec problem (since this way omits fontspec) or if the problem is somewhere
else.
Adam
— Adam
On 13-02-2011, at 09:01, Will Robertson wrote:
> On 2011-02-12 11:58:07 +1030, David Perry said:
>
>> In one of my fonts, I'm having a hard time getting the OT features to
>> work correctly in XeLaTeX.
>> If I include the following line:
>>\setmainfont[Numbers=Lowercase,Ligatures={Rare,Historical}]{Cardo}
>> then the oldstyle numerals and ligatures work fine. If I omit the
>> options from the \setmainfont command and add the features in the body
>> of the document using the normal \addfontfeature{ } or \addfontfeatures{
>> }, the features don't work (but there are no error messages during
>> compilation).
>
> Hmmm, is this a bug in fontspec? I can't think of an alternative explanation.
> Can you try it out with a different font?
>
>> Also, I cannot turn off the standard ligatures with the
>> Ligatures=NoCommon command.
>
> I think this is a font problem; this option corresponds to the OpenType
> "liga" feature.
>
> But I don't have much experience with creating OT features in a font; I hope
> others here can provide more info...
>
> Will
>
>
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
> http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
On 11-02-07 12:31, Jonathan Kew wrote: > A couple of possible workarounds: either modify the font file to avoid the > issue (Adam's analysis makes it clear how this could be done) -- provided > this is compatible with your license, of course -- or use a different > typeface that doesn't exhibit the problem. Adobe is one of the few major font vendors that do permit modification of their fonts for personal use. The solution to the problem would be to open the font in a font editor such as FontLab Studio or FontForge, then expanding class-based kerning and removing kerning classes, and then generating a new font with kerning written in this new way (i.e. as a flat list, not class-based). I might be able to write a Python script that does this (convert class into flat kerning) in a non-invasive manner (I actually have started this some time ago). Best, Adam -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
On 11-02-07 09:53, Jonathan Kew wrote:
> Adam,
>
> Thanks for the detailed analysis and testcase.
>
> It looks like this is an instance of
> http://bugs.icu-project.org/trac/ticket/7753.
Yes, seems like it. I've posted my testcase files there as well.
Best,
Adam
> JK
>
> On 7 Feb 2011, at 01:31, Adam Twardoch (List) wrote:
>
>> I have identified this issue as a serious bug in XeTeX.
>>
>> In MinionPro-Regular.otf (version 2.068 is the one I have, but it's
>> likely that it applies to all versions), the relevant kerning definition
>> excerpt looks like the following:
>>
>> feature kern {
>> lookup kern1 {
>> pos uni0423 uni0431.ital -53;
>>subtable;
>> pos [uni040E uni0423 uni0474] [uni0435 uni043E uni0441
>> uni0444 uni0451 uni0454 uni0473 uni0431.ital] -118;
>> } kern1;
>> } kern;
>>
>> This means that there is an individual kern value between uni0423
>> uni0431.ital with the value of -53, then a subtable break, then a
>> class-based value for the same pair of -118.
>>
>> Adobe InDesign CS5 correctly identifies the pair in the first subtable
>> (-53) as the one that it should apply, and ignores the second value. So
>> the kern comes out as -53.
>>
>> It very much looks like XeTeX *incorrectly* parses *both* subtables, and
>> applies a sum of both the individual and the class value (-53-118 =
>> -171), which results in a very deep kern, and therefore an overlap.
>>
>> This seems to be a serious, systematic bug in the way XeTeX (or its
>> underlying ICU Layout library) processes the GPOS table.
>>
>> I've made an isolated test case that confirmes it.
>>
>> I've created a test OpenType font. It defines a kerning pair A B -300, a
>> subtable break, and again the same pair. InDesign correctly applies only
>> the first value (-300), which is shown in the
>> SubtableKernTest-InDesign.pdf file. XeTeX applies both values
>> consecutively, which is shown in SubtableKernTest-XeTeX.pdf
>>
>> All the test files (.ttf, .fea feature definitions, .tex and two PDFs)
>> are available at
>> http://www.twardoch.com/tmp/SubtableKernTest.zip
>>
>> I've also sent the test files offline to Jonathan Kew.
>>
>> Many thanks to Alessandro Ceschini for raising the issue.
>>
>> Regards,
>> Adam
>>
>>
>>
>> --
>> Subscriptions, Archive, and List information, etc.:
>> http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
I have identified this issue as a serious bug in XeTeX.
In MinionPro-Regular.otf (version 2.068 is the one I have, but it's
likely that it applies to all versions), the relevant kerning definition
excerpt looks like the following:
feature kern {
lookup kern1 {
pos uni0423 uni0431.ital -53;
subtable;
pos [uni040E uni0423 uni0474] [uni0435 uni043E uni0441
uni0444 uni0451 uni0454 uni0473 uni0431.ital] -118;
} kern1;
} kern;
This means that there is an individual kern value between uni0423
uni0431.ital with the value of -53, then a subtable break, then a
class-based value for the same pair of -118.
Adobe InDesign CS5 correctly identifies the pair in the first subtable
(-53) as the one that it should apply, and ignores the second value. So
the kern comes out as -53.
It very much looks like XeTeX *incorrectly* parses *both* subtables, and
applies a sum of both the individual and the class value (-53-118 =
-171), which results in a very deep kern, and therefore an overlap.
This seems to be a serious, systematic bug in the way XeTeX (or its
underlying ICU Layout library) processes the GPOS table.
I've made an isolated test case that confirmes it.
I've created a test OpenType font. It defines a kerning pair A B -300, a
subtable break, and again the same pair. InDesign correctly applies only
the first value (-300), which is shown in the
SubtableKernTest-InDesign.pdf file. XeTeX applies both values
consecutively, which is shown in SubtableKernTest-XeTeX.pdf
All the test files (.ttf, .fea feature definitions, .tex and two PDFs)
are available at
http://www.twardoch.com/tmp/SubtableKernTest.zip
I've also sent the test files offline to Jonathan Kew.
Many thanks to Alessandro Ceschini for raising the issue.
Regards,
Adam
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
On 11-02-05 23:25, Alessandro Ceschini wrote: > OK, I got it know. Can you suggest me any workaround? This bug is very > annoying since the combination occurs frequently. I think you could search/replace for the combination and insert an additional positive TeX \kern there, but I don't really know how to do it properly. I know a few things about fonts, but very little about TeX. A. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
Ps. Technically speaking, in OpenType, kerning moves the right sidebearing of the first glyph in a pair. Typically, it does so to the left (if the kerning value is negative). In Minion Pro, the kerning value for this pair is -181, so the right sidebearing of the У glyph is moved by 181 font units to the left. But in XeTeX, it looks more like 250 units or so. A. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
On 11-02-05 23:15, Alessandro Ceschini wrote: > Sorry, I'd rather say there is too little space on top, not too much, > the two characters are practically stuck on top, while there should > be--FontForge and Pango show it--some additional space. Are you sure > our outputs are the same? Yes. Kerning typically works in the "negative" direction. Without kerning, the distance between those two glyphs would be much larger. Kerning reduces the distance, i.e. moves the Serbian "b" to the LEFT, but in XeTeX, it moves too much to the left. A. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
On 11-02-05 22:41, Alessandro Ceschini wrote: > Yeah, as I told you I'd taken a look in FontForge and it came out font > designers had anticipated such combination in the kerning pairs table. > In effect it works in PangoView but I can't figure out how to direct the > output toward a pdf, so I can't show you the right kerning, anyhow there > should be more space, that's obvious. > There should be some bug in XeTeX, I guess it doesn't look for kerning > pairs that involve alternate glyphs. Well, no, it certainly *does* look into for kerning pairs -- your and my tests obviously indicate that there is *lots* of kerning between the two glyphs in question, in fact, *too* much. So XeTeX does kern, it just does something wrong in the process, perhaps adding some additional kerning value on top. A. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
Sorry, I replied prematurely. I did have to change my document to
\documentclass{article}
\usepackage{fontspec}
\usepackage{polyglossia}
\setmainlanguage{Serbian}
\usepackage{xunicode}
\usepackage{xltxtra}
\setmainfont[Script=Cyrillic,Language=Serbian]{Minion Pro}
\begin{document}
\fontsize{24}{24}\selectfont Убить!
\end{document}
to get the Serbian variant, and you're right.
I've also tested it with a plain XeTeX variant:
\font\samplefont = "Minion Pro:script=cyrl;language=SRB" at 72bp
\samplefont
\setbox0 \hbox{Убить!}
\shipout\box0
\end
The font has the kerning definition:
@kc38_first_29 = [\uni040E \uni0423 \uni0474 ];
@kc38_second_16 = [\uni0435 \uni043E \uni0441 \uni0444 \uni0451 \uni0454
\uni0473 \uni0431.ital ];
pos @kc38_first_29 @kc38_second_16 -118;
and the kerning pair in question is \uni0423\uni0431.ital
So it should be kerned with the value -118. Unfortunately, it does seem
like the rendered kerning value is deeper than that.
Best,
Adam
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Kerning flaw with MinionPro & XeTex
On 11-01-09 23:07, Alessandro Ceschini wrote:
> \documentclass{article}
> \usepackage{fontspec}
> \setmainfont{Minion Pro}
> \usepackage{polyglossia}
> \setmainlanguage{Serbian}
> \usepackage{xunicode}
> \usepackage{xltxtra}
>
> \begin{document}
> \fontsize{24}{24}\selectfont Уб
> \end{document}
I tested this example on my Mac OS X 10.6 with TeXLive 10, and the
kerning comes out correctly.
A.
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] \XeTeXglyphbounds question
On 11-02-04 18:37, Adam Twardoch (List) wrote: > So, ideally something like \XeTeXboxbounds would be great: work the same > way as \XeTeXglyphbounds but for a box (taking 1, 2, 3, 4 as parameter, > and a box). Of course, if \XeTeXglyphmetrics=1, \XeTeXboxbounds2 (top) and \XeTeXboxbounds4 (bottom) should each report 0, while if \XeTeXglyphmetrics=0, \XeTeXboxbounds2 and \XeTeXboxbounds4 would report precisely the differences that I'm obtaining by comparing \ht and \dp of two boxes set with alternating value of \XeTeXglyphmetrics. That would be the logical consequence, I think. A. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] \XeTeXglyphbounds question
On 11-02-04 14:27, Jonathan Kew wrote: > Unfortunately, I don't think there's currently any way to do that. (Well, no > way within xetex, that is -- you could of course ship the box to the output > file, then post-process that with a tool of some kind to determine the glyph > ID, and then re-run the job using that information as input. But that's a > terribly cumbersome way to get to where you're trying to go!) > > It might be nice to have a command that could "look inside" boxes like that > and tell you the glyph IDs but then you'll probably find yourself wanting > their positions, too and then what if the contents of the box are more > complex than just a series of glyphs? Figuring out a usable TeX-level > interface to this could become awfully complex... Ah, I was afraid you're going to say that :) I do like the way \XeTeXglyphmetrics works, because, as you could see in my sample file I sent you offline, by typesetting two boxes, one with the command =0 and another =1, I can get the \ht and \dp dimensions and compare them, thus getting a reliable difference in "font height" and "glyph-derived height", and -- which is very important -- I get the two values separately (height and depth). And that does work on "any" box, i.e. if I put some non-textual objects there, the results will be the same, so what. As you might imagine, my second goal would be to get the left "sidebearing" and the right "sidebearing" (i.e. the differences between the inked bounding box and the declared typesetting origin). \XeTeXglyphbounds gives me that for a single glyph, but since there is no way to determine which glyphs will be used after a typesetting process, \XeTeXglyphbounds is only of theoretical value. I think the usefulness of having just the two edge values (the "left" and the "right" bounds) for a box would be sufficient for a large amount of purposes. This could be used to do custom margin alignment and perform any sort of corrections to the horizontal positioning of the box. Just like in case of \XeTeXglyphmetrics, I don't really desperately need to know WHICH glyph is "bumping up" the overall vertical height of a box, when I use it vs. not use it. The mere ability to measure the difference _per box_ is already very helpful. So, ideally something like \XeTeXboxbounds would be great: work the same way as \XeTeXglyphbounds but for a box (taking 1, 2, 3, 4 as parameter, and a box). As I said, that would already be extremely useful in a variety of cases, even though I wouldn't have access to individual glyph IDs and position inside the box. Just the outer differences between the box size and the rendered glyph stream size. It's much less common a case that I need to know all the details of my glyph stream (and, as you said, it's hard to report reliably the inner structure of a box if its contents is complex). But a simple interface to report the difference between the "inked" bounding box and the metrics reported using standard means would be a huge helper. I don't know how feasible this is, though. Many thanks for your help so far! Best, Adam -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] \XeTeXglyphbounds question
(Plain XeTeX, not XeLaTeX).
Imagine I use a font which uses contextual alternates such as:
\font\samplefont = "Zapfino Extra LT Pro:+calt" at 72bp
\samplefont
\def \sampletext{finality}
\XeTeXuseglyphmetrics=1
\setbox1 \hbox{\sampletext \/}
So now, XeTeX has produced a box which has a series of glyph IDs. The
left edge of the box is at the origin point of the "f" glyph. I want to
add extra padding on the left through the use of
\XeTeXglyphbounds1
I could use:
\XeTeXcharglyph`f
but this only gives me the glyph ID of the *default* glyph for the "f"
character. Yet since the font uses contextual alternates, I may end up
having any alternate "f" there, depending on the contents of \sampletext
So: how do I find out which glyph ID is the first (or 2nd, or last, for
that matter) in my box?
Best,
Adam
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] Generating a PDF which is cropped to the bounding box?
Jonathan etc., I have a simple XeTeX script that produces one line of text. The line (or the artwork, in general) has a certain bounding box. I'd like to generate a PDF that is cropped exactly to the size of that artwork. Can I do this directly in XeTeX? If not, is there any way to do it directly using ghostscript? Thanks in advance, Adam -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
