Re: [XeTeX] TECkit map for Latin alphabet to Unicode IPA
2011/10/30 Daniel Greenhoe dgreen...@gmail.com:
On Sat, Oct 29, 2011 at 1:11 PM, Andy Lin kir...@gmail.com wrote:
This is actually the reason I abandoned developing the map file
further. I had started based on the textipa replacements that I knew,
and then I discovered all the additional commands and realized that
they could not be implemented by TECkit along ...
For better or for worse, I would like to finish what I have started.
Currently my problem is finding a good method for typesetting glyphs
with diacritics. For example the b with a small circle under it
(voiceless b) is quite important in Chinese. Any suggestions for
typesetting glyphs with diacritics? That is, what would be a good way
to put a small circle under a letter without using the tipa package?
Maybe it is about at this point where my desired TECkit map only
solution starts to break down.
It depends... In Linux you can define your own xkb map and thus have
all accents on your keyboard. It is possible to define macros in emacs
but both these solutins are nonportable, you cannot give them to a
user who prefers another text editor on a different platform. TECkit
map is portable, you just send the map and instruct users how to
install it.
Dan
On Sat, Oct 29, 2011 at 1:11 PM, Andy Lin kir...@gmail.com wrote:
On Thu, Oct 27, 2011 at 04:06, Daniel Greenhoe dgreen...@gmail.com wrote:
What I would really like is a drop in solution involving a TECkit
map only. That is, I would like to be able to hand such a map off to a
linguist, and to tell him/her to simply add in something like this to
his/her tex file:
\addfontfeatures{Mapping=tipa2uni}.
And that's it --- just one support file: a TECkit map file.
This is actually the reason I abandoned developing the map file
further. I had started based on the textipa replacements that I knew,
and then I discovered all the additional commands and realized that
they could not be implemented by TECkit along (don't get me wrong,
TECkit maps are very powerful, I've written one to convert
arabtex-like romanization into Persian). After tipa support was added
to xunicode, I just used that instead.
If this single line solution is important to you, you could write a
wrapper package that calls xunicode, adding whichever redefinitions
you need.
-Andy
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] TECkit map for Latin alphabet to Unicode IPA
2011/10/30 Zdenek Wagner zdenek.wag...@gmail.com:
It depends... In Linux you can define your own xkb map and thus have
all accents on your keyboard. It is possible to define macros in emacs ...
Thank you for your feedback. However, I was not referring to keyboard
input methods, I meant how do I, for example, create a glyph
containing a Latin letter with a small circle under it?
I know that LaTeX in general supports the \r command that puts a
circle over or kind of over the top of a letter (e.g. \r{a} should
produce something like an a with a small circle over it). But with the
exception of Latin letters with descenders (like g), IPA encourages
putting the circles under the letters rather than over them.
In short, what would be a good general method for creating glyphs
with assorted diacritics without resorting to editing the font itself
(e.g. with FontForge, etc.)?
Dan
2011/10/30 Zdenek Wagner zdenek.wag...@gmail.com:
2011/10/30 Daniel Greenhoe dgreen...@gmail.com:
On Sat, Oct 29, 2011 at 1:11 PM, Andy Lin kir...@gmail.com wrote:
This is actually the reason I abandoned developing the map file
further. I had started based on the textipa replacements that I knew,
and then I discovered all the additional commands and realized that
they could not be implemented by TECkit along ...
For better or for worse, I would like to finish what I have started.
Currently my problem is finding a good method for typesetting glyphs
with diacritics. For example the b with a small circle under it
(voiceless b) is quite important in Chinese. Any suggestions for
typesetting glyphs with diacritics? That is, what would be a good way
to put a small circle under a letter without using the tipa package?
Maybe it is about at this point where my desired TECkit map only
solution starts to break down.
It depends... In Linux you can define your own xkb map and thus have
all accents on your keyboard. It is possible to define macros in emacs
but both these solutins are nonportable, you cannot give them to a
user who prefers another text editor on a different platform. TECkit
map is portable, you just send the map and instruct users how to
install it.
Dan
On Sat, Oct 29, 2011 at 1:11 PM, Andy Lin kir...@gmail.com wrote:
On Thu, Oct 27, 2011 at 04:06, Daniel Greenhoe dgreen...@gmail.com wrote:
What I would really like is a drop in solution involving a TECkit
map only. That is, I would like to be able to hand such a map off to a
linguist, and to tell him/her to simply add in something like this to
his/her tex file:
\addfontfeatures{Mapping=tipa2uni}.
And that's it --- just one support file: a TECkit map file.
This is actually the reason I abandoned developing the map file
further. I had started based on the textipa replacements that I knew,
and then I discovered all the additional commands and realized that
they could not be implemented by TECkit along (don't get me wrong,
TECkit maps are very powerful, I've written one to convert
arabtex-like romanization into Persian). After tipa support was added
to xunicode, I just used that instead.
If this single line solution is important to you, you could write a
wrapper package that calls xunicode, adding whichever redefinitions
you need.
-Andy
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz
--
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-live] Ftuture state of XeTeX in TeXLive
On Sun, Oct 30, 2011 at 5:33 PM, Paul Isambert zappathus...@free.fr wrote: Le 30/10/2011 06:25, Vafa Khalighi a écrit : XeTeX font support is heaps better and stable than what luaotfload package offers and I guess that is why many users still like using xetex instead luatex. I personally believe that it is a bad practice that luaotfload just copies ConTeXt code, it should not be deeply dependent on ConTeXt because Hans may want to try experimenting with some features today and next day he gets rid of them just like the recent updates of luaotfload that Khaled talked about it. I think, this is awful! What should users who used those features (and need it heavily in their daily typesetting tasks, do?). They wake up one day and suddenly see that yes, luaotfload does not provide the features they need. luaotfload needs to be written from scratch independent of any ConTeXt code. An independent fontloader could very well be unstable too. But anyway I suppose this will happen some day; relying on Hans's code is the only solution for the moment, because nobody has written a public alternative (and writing such an alternative is no simple task), but I don't suppose it will remain so. As far as I'm concerned, I don't use luaotfload but my own fontloader. It is not public for the moment because it doesn't do much more than what I need to do. But I have good hope that somebody will some day come with a full solution; or perhaps different people will write partial solutions (someone could write something for latin typography, somebody else could devise an arabic fontloader, and so on and so forth). The problem is, it's easier to blame luaotfload for its uncertain status than to sit down and write a replacement; so please let's not forget that without luaotfload LuaTeX wouldn't be different from PDFTeX as far as fonts are concerned. Best, Paul -- 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-live] Ftuture state of XeTeX in TeXLive
The problem is, it's easier to blame luaotfload for its uncertain status than to sit down and write a replacement; so please let's not forget that without luaotfload LuaTeX wouldn't be different from PDFTeX as far as fonts are concerned. That was not what I was trying to convey. What I meant to say was that luaotfload needs to work out its own implementation. If it relies on ConTeXt, then it has obviously no control over the code and hence it would create some major problems. Indeed I am grateful to Hans, Khaled and anyone else who has been working on luaotfload but a LaTeX or a generic TeX package needs to implement its own code indepently. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] TECkit map for Latin alphabet to Unicode IPA
On 30/10/2011, at 8:11 PM, Daniel Greenhoe wrote:
On Sun, Oct 30, 2011 at 4:33 PM, Peter Dyballa peter_dyba...@web.de wrote:
With COMBINING RING BELOW, U+0325?
Yes --- How do I in general put, for example, U+0325 below U+0062,
while still maintaining proper alignment (e.g. the bottom of the b
(U+0062) with a ring (U+0325) below it is still aligned with the
bottom of an adjacent c (U+0063) with nothing below it)?
With Xunicode loaded, does this not do what you want?
c\textsubring{b}c
or cb0325c (with no extra package).
It is up to the font to implement the placement.
XeTeX just receives the codes for the characters/glyphs.
You can write a macro to simplify the input, once you are
sure that you know what you want, and how to get it.
Dan
Hope this helps,
Ross
Ross Moore ross.mo...@mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 (0)2 9850 8955
Sydney, Australia 2109 fax: +61 (0)2 9850 8114
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] TECkit map for Latin alphabet to Unicode IPA
On Sun, Oct 30, 2011 at 5:50 PM, Ross Moore ross.mo...@mq.edu.au wrote:
With Xunicode loaded, does this not do what you want?
c\textsubring{b}c
On ctan at http://www.ctan.org/tex-archive/macros/xetex/latex/xunicode
there is no documentation about xunicode other than a brief readme. Is
there currently any documentation available somewhere that might
describe the commands (like \textsubring) and other facilities
available via the xunicode package?
Dan
On Sun, Oct 30, 2011 at 6:25 PM, Daniel Greenhoe dgreen...@gmail.com wrote:
On Sun, Oct 30, 2011 at 5:50 PM, Ross Moore ross.mo...@mq.edu.au wrote:
With Xunicode loaded, does this not do what you want?
c\textsubring{b}c
or cb0325c (with no extra package).
Yes, both of those work great! Thank you!
Dan
On Sun, Oct 30, 2011 at 5:50 PM, Ross Moore ross.mo...@mq.edu.au wrote:
On 30/10/2011, at 8:11 PM, Daniel Greenhoe wrote:
On Sun, Oct 30, 2011 at 4:33 PM, Peter Dyballa peter_dyba...@web.de wrote:
With COMBINING RING BELOW, U+0325?
Yes --- How do I in general put, for example, U+0325 below U+0062,
while still maintaining proper alignment (e.g. the bottom of the b
(U+0062) with a ring (U+0325) below it is still aligned with the
bottom of an adjacent c (U+0063) with nothing below it)?
With Xunicode loaded, does this not do what you want?
c\textsubring{b}c
or cb0325c (with no extra package).
It is up to the font to implement the placement.
XeTeX just receives the codes for the characters/glyphs.
You can write a macro to simplify the input, once you are
sure that you know what you want, and how to get it.
Dan
Hope this helps,
Ross
Ross Moore ross.mo...@mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 (0)2 9850 8955
Sydney, Australia 2109 fax: +61 (0)2 9850 8114
--
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-live] Ftuture state of XeTeX in TeXLive
On Sun, Oct 30, 2011 at 04:25:21PM +1100, Vafa Khalighi wrote: XeTeX font support is heaps better and stable than what luaotfload package offers and I guess that is why many users still like using xetex instead luatex. I personally believe that it is a bad practice that luaotfload just copies ConTeXt code, it should not be deeply dependent on ConTeXt because Hans may want to try experimenting with some features today and next day he gets rid of them just like the recent updates of luaotfload that Khaled talked about it. I think, this is awful! What should users who used those features (and need it heavily in their daily typesetting tasks, do?). They wake up one day and suddenly see that yes, luaotfload does not provide the features they need. luaotfload needs to be written from scratch independent of any ConTeXt code. The situation is not as bad as you make it seems, what have gone is two minor features that IMO was a mistake to provide them in the first place, but since we are talking about a yet to be released version of luaotfload, there might be an alternate solution at the time of release. Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. The main goal of luaotfload, besides having an OpenType engine for lualatex, is too make sure we don't end up with two different OpenType implementations for luatex, each broken in its own way. OpenType is such a horribly documented standard that is there is no single implementation of it that does not have its own share of bugs (it is often not easy to tell if a bug is a bug or since the documentation are so fuzzy in certain areas). Regards, Khaled -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny khaledho...@eglug.org wrote: On Sun, Oct 30, 2011 at 04:25:21PM +1100, Vafa Khalighi wrote: XeTeX font support is heaps better and stable than what luaotfload package offers and I guess that is why many users still like using xetex instead luatex. I personally believe that it is a bad practice that luaotfload just copies ConTeXt code, it should not be deeply dependent on ConTeXt because Hans may want to try experimenting with some features today and next day he gets rid of them just like the recent updates of luaotfload that Khaled talked about it. I think, this is awful! What should users who used those features (and need it heavily in their daily typesetting tasks, do?). They wake up one day and suddenly see that yes, luaotfload does not provide the features they need. luaotfload needs to be written from scratch independent of any ConTeXt code. The situation is not as bad as you make it seems, what have gone is two minor features that IMO was a mistake to provide them in the first place, but since we are talking about a yet to be released version of luaotfload, there might be an alternate solution at the time of release. Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. If plugging harfbuzz into luatex does not require a huge effort, it could serve as bridge from xetex to luatex while a more principled design is being created. Principles are nice, and have benefits over the long haul, but in cases where the design is evolving it really helps to get an implementation into the hands of users and let them point out the areas where work is needed. The main goal of luaotfload, besides having an OpenType engine for lualatex, is too make sure we don't end up with two different OpenType implementations for luatex, each broken in its own way. OpenType is such a horribly documented standard that is there is no single implementation of it that does not have its own share of bugs (it is often not easy to tell if a bug is a bug or since the documentation are so fuzzy in certain areas). The way to bring clarity in cases of fuzzy standards is for one implementation, perhaps harfbuzz-ng is a candidate, as the reference and try to match that behaviour. The reference implementation won't be perfect, but needs to be open to change as problems are identified. -- George N. White III aa...@chebucto.ns.ca Head of St. Margarets Bay, Nova Scotia -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Future state of XeTeX in TeXLive
On 2011-10-28 21:02, Zdenek Wagner wrote: 2011/10/28msk...@ansuz.sooke.bc.ca: On Fri, 28 Oct 2011, William Adams wrote: majority of documents are created using GUI tools. What use cases are better served by batch mode, and in what cases is TeX used by default because of available GUI tools refuse to play. Large database publications. Variable data printing. Also, anything where documents end up checked into the source control and configuration management systems used for software development. It's really nice to be able to compile my TeX documents along with my code. I can't do that with GUI tools. Documents being written by several people in cooperation in real time (usually living in a versioning system) Documents that have to be rendered from sources on several different platforms Documents that have to be rendered from sources years later Documents containing math Documents created on-the-fly by a web service Documents produced by people with motor or vision disabilities which make it hard for them to use a WYSIWYG/GUI tool. (I have both a motor disability and some vision difficulties, but that shouldn't be a requirement for caring about the issue.) BTW: is there a symmary of Xe(La)TeX/LuaTeX differences somewhere? I can't say that I'm wild about the prospect of having to learn another programming language on top of LaTeX to get things working. This said I use perlTeX quite a bit, so I might have a gain in learning Lua(TeX) all the same. /bpj -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
Le 30/10/2011 13:20, George N. White III a écrit : On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny khaledho...@eglug.org wrote: Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. If plugging harfbuzz into luatex does not require a huge effort, it could serve as bridge from xetex to luatex while a more principled design is being created. Principles are nice, and have benefits over the long haul, but in cases where the design is evolving it really helps to get an implementation into the hands of users and let them point out the areas where work is needed. As far as I can see, the principles behind LuaTeX are pretty clear; it offers tools, not solutions. Sometimes that makes it apparently slow-witted, like TeX itself, because it refuses to implement solutions that seem successful elsewhere. But one shouldn't forget that (Lua)TeX is an extremely sophisticated typographic system, and that flexibility is an integral part of it. Using HarfBuzz would probably offer a simple solution, but you'd lose what makes LuaTeX so worthwhile. Best, Paul -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
On Sun, Oct 30, 2011 at 04:29:18PM +0100, Paul Isambert wrote: Le 30/10/2011 13:20, George N. White III a écrit : On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny khaledho...@eglug.org wrote: Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. If plugging harfbuzz into luatex does not require a huge effort, it could serve as bridge from xetex to luatex while a more principled design is being created. Principles are nice, and have benefits over the long haul, but in cases where the design is evolving it really helps to get an implementation into the hands of users and let them point out the areas where work is needed. As far as I can see, the principles behind LuaTeX are pretty clear; it offers tools, not solutions. Sometimes that makes it apparently slow-witted, like TeX itself, because it refuses to implement solutions that seem successful elsewhere. But one shouldn't forget that (Lua)TeX is an extremely sophisticated typographic system, and that flexibility is an integral part of it. Using HarfBuzz would probably offer a simple solution, but you'd lose what makes LuaTeX so worthwhile. Best, Paul What is so worthwile on cripling one scripting language with another one? P. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
On Sun, Oct 30, 2011 at 09:20:19AM -0300, George N. White III wrote: On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny khaledho...@eglug.org wrote: On Sun, Oct 30, 2011 at 04:25:21PM +1100, Vafa Khalighi wrote: XeTeX font support is heaps better and stable than what luaotfload package offers and I guess that is why many users still like using xetex instead luatex. I personally believe that it is a bad practice that luaotfload just copies ConTeXt code, it should not be deeply dependent on ConTeXt because Hans may want to try experimenting with some features today and next day he gets rid of them just like the recent updates of luaotfload that Khaled talked about it. I think, this is awful! What should users who used those features (and need it heavily in their daily typesetting tasks, do?). They wake up one day and suddenly see that yes, luaotfload does not provide the features they need. luaotfload needs to be written from scratch independent of any ConTeXt code. The situation is not as bad as you make it seems, what have gone is two minor features that IMO was a mistake to provide them in the first place, but since we are talking about a yet to be released version of luaotfload, there might be an alternate solution at the time of release. Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. If plugging harfbuzz into luatex does not require a huge effort, it could serve as bridge from xetex to luatex while a more principled design is being created. It would be better to have XeTeX with a stable HarfBuzz-ng support. Actually, I think little people need more then than what XeTTeX acctually provides... -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
Are you talking about TeX--XeT bidirectional typesetting algorithm? No, It has several major bugs and it is not perfect for RTL typesetting (ok but not perfect). On Mon, Oct 31, 2011 at 3:18 AM, Petr Tomasek toma...@etf.cuni.cz wrote: On Sun, Oct 30, 2011 at 09:20:19AM -0300, George N. White III wrote: On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny khaledho...@eglug.org wrote: On Sun, Oct 30, 2011 at 04:25:21PM +1100, Vafa Khalighi wrote: XeTeX font support is heaps better and stable than what luaotfload package offers and I guess that is why many users still like using xetex instead luatex. I personally believe that it is a bad practice that luaotfload just copies ConTeXt code, it should not be deeply dependent on ConTeXt because Hans may want to try experimenting with some features today and next day he gets rid of them just like the recent updates of luaotfload that Khaled talked about it. I think, this is awful! What should users who used those features (and need it heavily in their daily typesetting tasks, do?). They wake up one day and suddenly see that yes, luaotfload does not provide the features they need. luaotfload needs to be written from scratch independent of any ConTeXt code. The situation is not as bad as you make it seems, what have gone is two minor features that IMO was a mistake to provide them in the first place, but since we are talking about a yet to be released version of luaotfload, there might be an alternate solution at the time of release. Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. If plugging harfbuzz into luatex does not require a huge effort, it could serve as bridge from xetex to luatex while a more principled design is being created. It would be better to have XeTeX with a stable HarfBuzz-ng support. Actually, I think little people need more then than what XeTTeX acctually provides... -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
On Mon, Oct 31, 2011 at 03:29:30AM +1100, Vafa Khalighi wrote: Are you talking about TeX--XeT bidirectional typesetting algorithm? Sorry that was a typo, am using a slow connection and a mutt on a server over ssh... No, It has several major bugs and it is not perfect for RTL typesetting (ok but not perfect). I meant XeTeX as opposed to LuaTeX... On Mon, Oct 31, 2011 at 3:18 AM, Petr Tomasek toma...@etf.cuni.cz wrote: On Sun, Oct 30, 2011 at 09:20:19AM -0300, George N. White III wrote: On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosny khaledho...@eglug.org wrote: On Sun, Oct 30, 2011 at 04:25:21PM +1100, Vafa Khalighi wrote: XeTeX font support is heaps better and stable than what luaotfload package offers and I guess that is why many users still like using xetex instead luatex. I personally believe that it is a bad practice that luaotfload just copies ConTeXt code, it should not be deeply dependent on ConTeXt because Hans may want to try experimenting with some features today and next day he gets rid of them just like the recent updates of luaotfload that Khaled talked about it. I think, this is awful! What should users who used those features (and need it heavily in their daily typesetting tasks, do?). They wake up one day and suddenly see that yes, luaotfload does not provide the features they need. luaotfload needs to be written from scratch independent of any ConTeXt code. The situation is not as bad as you make it seems, what have gone is two minor features that IMO was a mistake to provide them in the first place, but since we are talking about a yet to be released version of luaotfload, there might be an alternate solution at the time of release. Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. If plugging harfbuzz into luatex does not require a huge effort, it could serve as bridge from xetex to luatex while a more principled design is being created. It would be better to have XeTeX with a stable HarfBuzz-ng support. Actually, I think little people need more then than what XeTTeX acctually provides... -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
Le 30/10/2011 17:20, Petr Tomasek a écrit : On Sun, Oct 30, 2011 at 04:29:18PM +0100, Paul Isambert wrote: Le 30/10/2011 13:20, George N. White III a écrit : On Sun, Oct 30, 2011 at 7:42 AM, Khaled Hosnykhaledho...@eglug.org wrote: Writing an OpenType layout engine is not a simple task, and you can judge from the many years it toke FOSS community to have a really good one, HarfBuzz (the name luaotfload is misleading, font loading is about the easiest part of luaotfload, OpenType implementation is really what matters.) If it were for me, I'd plug HarfBuzz into luatex proper and call it a day, but this does not align well with the design principles of luatex so it is unlikely to happen. If plugging harfbuzz into luatex does not require a huge effort, it could serve as bridge from xetex to luatex while a more principled design is being created. Principles are nice, and have benefits over the long haul, but in cases where the design is evolving it really helps to get an implementation into the hands of users and let them point out the areas where work is needed. As far as I can see, the principles behind LuaTeX are pretty clear; it offers tools, not solutions. Sometimes that makes it apparently slow-witted, like TeX itself, because it refuses to implement solutions that seem successful elsewhere. But one shouldn't forget that (Lua)TeX is an extremely sophisticated typographic system, and that flexibility is an integral part of it. Using HarfBuzz would probably offer a simple solution, but you'd lose what makes LuaTeX so worthwhile. Best, Paul What is so worthwile on cripling one scripting language with another one? I don't understand your (I suppose) rhetorical question. Do you mean crippling TeX with Lua? If that's how you see LuaTeX, I think there isn't much we're going to agree on. Best, Paul -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
On Sun, Oct 30, 2011 at 05:18:18PM +0100, Petr Tomasek wrote: Actually, I think little people need more then than what XeTTeX acctually provides... 640kb ought to be enough for anybody. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
Khaled Hosny wrote: On Sun, Oct 30, 2011 at 05:18:18PM +0100, Petr Tomasek wrote: Actually, I think little people need more then than what XeTTeX acctually provides... 640kb ought to be enough for anybody. I think there is a world market for maybe five computers. -- Thomas Watson, Chairman of IBM, 1943. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
On Oct 30, 2011, at 1:10 PM, Philip TAYLOR (Webmaster, Ret'd) wrote: Khaled Hosny wrote: On Sun, Oct 30, 2011 at 05:18:18PM +0100, Petr Tomasek wrote: Actually, I think little people need more then than what XeTTeX acctually provides... 640kb ought to be enough for anybody. I think there is a world market for maybe five computers. -- Thomas Watson, Chairman of IBM, 1943. Howdy, Yeah... given the state of technology back then he was probably correct. We all have an awful lot of thanks that we should give to NASA for the practical application of Solid State Physics to practical devices. Good Luck, Herb Schulz (herbs at wideopenwest dot com) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] TECkit map for Latin alphabet to Unicode IPA
Hello Daniel,
On 30/10/2011, at 21:41, Daniel Greenhoe dgreen...@gmail.com wrote:
On Sun, Oct 30, 2011 at 5:50 PM, Ross Moore ross.mo...@mq.edu.au wrote:
With Xunicode loaded, does this not do what you want?
c\textsubring{b}c
On ctan at http://www.ctan.org/tex-archive/macros/xetex/latex/xunicode
there is no documentation about xunicode other than a brief readme. Is
there currently any documentation available somewhere that might
describe the commands (like \textsubring) and other facilities
available via the xunicode package?
No. Practically every LaTeX macro from standard packages supporting legacy font
encodings, resulting in a character or accent/diacritic that has a Unicode code
point, has a corresponding declaration in Xunicode, for backward compatibility
reasons. There is no point in describing how these are used. That is the job of
the legacy packages, and would result in hundreds, if not thousands, of pages
of documentation that could never be definitive anyway.
The file xunicode.sty is a plain text file, with a History section. You can
search for the Hex string of a specific character, to find whether it is
implemented or not. This will find the name of the macro, and usually will
locate other characters in the same Unicode block, or having similar
functionality.
Dan
Hope this helps,
Ross
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] TECkit map for Latin alphabet to Unicode IPA
I second looking through xunicode.sty. Most of the tipa commands are the same, although a couple were altered, as precedence was given to the math symbols (I think). The comments in file explain why a particular command was assign to a particular character in these cases, and IIRC, tell you what command has been assigned to an alternate character. Once you find the commands you want, you can use TexMaker and create a palette of characters that you use most often. Or you can create a custom keyboard layout with dead keys to input the characters (we distributed one such keyboard for a project once, aside from Windows throwing a security dialogue, we didn't have much trouble with it). -Andy -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
