Re: [XeTeX] Hyphenation around „ß“
Hi Susan, All, the is no law in Germany that dictates or requires one by "law" to use one particular orthography. Though, the new reformed "reformed" orthography is taught in school as the correct form to be used! The general rules is to stick to one of the orthography and you are safe. Since TEX et al. is not a spellchecker we only need to worry about hyphenation, and not if ß is used or not! regards Keith. Am 13.01.2014 um 15:02 schrieb Susan Dittmar : > Dear Phil, > > Philip Taylor schrieb: >> My 1999 edition of the Collins German Dictionary (reformed orthography) >> gives only "wusste", and gives it as the preterite of "wissen". >> Does "wußte" exist in the Reformed Orthography, and if so, >> with what meaning ? > > it does not exist in the Reformed Orthography, that's right. But there's > strong resistance, as you probably already noticed, against this reform. So > although Law decided for "wußte" to no longer be correct, most people here > (at least most of those who finished school before the reform) still use, and > insist on, the old form. > > Btw, the reform only applies to Germany. To my knowledge it does not apply to > other German-speaking countries like Austria and Suisse. > > Hope that helps lessen the confusion, > > Susan > > > > > -- > 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] Hyphenation around „ß“
Hi All, according to the new reformed rules, the use of ß is dependent on the length of the preceding vowel. So, according to the latest reformed orthography rules wusste is correct. Some words seem to be still allowed with the older orthography, but the they are exceptions. Either way, the way ß is hyphenated stays the same! So, whenever a ß shows up the hyphenation method stays. For all interrest there has been two main reforms to the reform of 1996. To my knowledge the latest was in 2006. Most of these reforms were regarding spelling to reduce much of the confusion and many exceptions introduced in 1996. Gruß, regards Keith Am 13.01.2014 um 13:08 schrieb Philip Taylor : > > > Georg Pfeiffer wrote: > >> There should be no difference, because the used word in the test have >> the same spelling and hyphenation in both variants. The patterns should >> be the same. The problem sticks anywhere between xetex and the output >> (LaTeX for XeTeX, xltxtra, babel, polygrossia). > > Well, I am confused (not an unusual state of affairs, many will opine). > My 1999 edition of the Collins German Dictionary (reformed orthography) > gives only "wusste", and gives it as the preterite of "wissen". > > Does "wußte" exist in the Reformed Orthography, and if so, > with what meaning ? > > ** Phil. > > [1] Collins German Dictionary, ISBN-10 0-00-470585-8, > unabbridged, 4th edition, > 2000 pp. > > > -- > 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] xetex and the unicode bidirectional algorithm.
Hi All, Phillip. Let recap the situation here: The original post from Scott stated he had a problem going from his wiki to PDF via Xe(La)TeX! His problem involved texts with mixed directionality. I did not express myself very well and should have said that in unicode one can identify characters with RTL directionality and language as such. Sorry if this miss understanding caused to much noise and just last nicht I realized the fact. I was always under the impression that the main emphasis was on RTL-languages. Phillip Vietnamese is LTR, to my knowledge and I did not state that unicode can identify all languages. The fact remains that one can identify the directionality of code points. How they have to be processed is another matter. The Bidi-Algorithm is in the standard. Which helps getting the directional display right. The fact remains that he can identify his problem cases and handle them appropriately. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
Hi Phillip, I will repeat I do not know Vietnamese so I can not give you the utf-8 sequence for it. All I can say that in utf-8 the singular letters will be encoded in multi-bytes whereas the english letters will be just one byte. Now, i also, mentioned that differentiating western language poses a different matter! "sang" in English and "sang" in German an Austrian can not be singularly deferentiated as to which language it belongs to! All latin characters/letters. Now, if "sang" is true Vietnamese and not a latinized form stand corrected! Though I have a feeling it is latinized! If we are talking of the phonetic reprsentation, then a analysis on text and belong singular text level is required. It has been mentioned by others that seems to be a lack of multi-lingual utf-8 editors(input methods) on the other side also, Xe(La)TeX lack of implementation of properly handling the unicode standard. It is not the standard that is the problem, but the implementation of input and the implementation of the output method. True enough, Unicode is not by far finish and is still evolving with all the cavets involved. Yet, the problem here does arises out of the fact that the unicode standard and utf-8 encoding/decoding is inadequate, but in its implementation. The culprit is not utf-8! Am 09.12.2013 um 23:51 schrieb Philip Taylor : > > > Keith J. Schultz wrote: >> Hi Phillip, >> >> 1) I do not know Vietnamese! >> >> 2) If I did uses the proper BMP would give me the answer. >> As "sang would be a sequence of singualr octcets, and Vietnamese >> would use multi-byte sequences! >> >> case closed! Like I mentioned there are often ways used to reduce the length >> of >> the multibyte sequences. In that case one has to know the processed use to >> get the proper >> unicode character code! > > It is not necessary to "know" a language in order to be able to > algorithmically determine in which language a particular stretch > of text is written, if such algorithmic determination is possible. > I do not "know" Hebrew, but even I know that "בית דין" is Hebrew > and that "你好" is not. What I do not know (and what I challenge > you to tell us" is whether "sang" is English or Vietnamese. > > You wrote : "for efficiency reasons, utf-8 strings are not properly > encoded and programs assume a particular language, to save space." > > I invited you to tell us (the XeTeX list members, that is) what > would be a "properly encoded utf-8 string" for the sequence > "sang" which would enable a computer algorithm to determine > whether that string was "sang" (Vietnamese) or "sang" (English). > > I am still hoping that you will be able to tell us what that > properly encoded utf-8 string is, rather than just metaphorically > waving your arms in the air while throwing around phrases such as > "proper BMP", "singular octets" and "multi-byte sequences". > > Philip Taylor > > > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
Hi Khaled, I would agree with you if the text was not encoded in unicode! A properly encoded utf-8 string should contain everything you need! Unfortunately, for efficiency reasons, utf-8 strings are not properly encoded and programs assume a particular language, to save space. In multi-language environments methods are used for efficiency to make sure the system uses the correct language! It is not the fault of utf-8, but the way it is implemented. As far as the methods you point to, they are for identify texts of unknown origine and possibly of unknown encoding or an encoding that already has not identified the language. Am 09.12.2013 um 10:38 schrieb Khaled Hosny : > On Mon, Dec 09, 2013 at 09:22:10AM +0100, Keith J. Schultz wrote: >> Hi Khaled, >> >> your question can not be serious! > > No, it is. > >> It is pretty much in the standard! > > No. > >> True enough that for most western languages american, english, spanish, >> german, austrian, etc. this is somewhat difficult. Yet, these are not >> causing the problems. > > You can’t identify the language of a Unicode string just by examining > the Unicode properties for the characters in that string, simply because > such Unicode property does not exist. Language identifications involves > quite some statistical analysis[1]. You can identify scripts using > Unicode properties quite reliably, though. > > 1. > https://en.wikipedia.org/wiki/Language_identification#Statistical_approaches > > Regards, > Khaled [snip, snip] -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
Hi Khaled, your question can not be serious! It is pretty much in the standard! True enough that for most western languages american, english, spanish, german, austrian, etc. this is somewhat difficult. Yet, these are not causing the problems. regards Keith. Am 05.12.2013 um 09:46 schrieb Khaled Hosny : > On Thu, Dec 05, 2013 at 09:41:04AM +0100, Keith J. Schultz wrote: >> Hi Scott, >> >> We are talking Unicode here right! What is there to guess? > > And how do you, using Unicode, tell in what language is this line > written? > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
Hi Scott, We are talking Unicode here right! What is there to guess? Then there is always the possibility of having the text tagged when written by the original author. Of course, only when you can control his input tools. Lua(La)TeX has other great feature. You have a complete programming language you can use to maniplulate data/text before it is processed by TeX or even after it has been processed by TeX. This gives easier ways of manipulating and processing text than TeX has. regards Keith. Am 04.12.2013 um 14:24 schrieb C. Scott Ananian : > The goal is to match the Unicode bidi algorithm, because that is how the web > page displays and thus how the original author saw the text as they wrote. > Guessing the proper language tag to use is likely infeasible; note that the > example given contains titles in Turkish as well as English. The safest > option is probably to treat embedded LTR text in an RTL context as 'exotic' > and not to attempt hyphenation. > > I've heard it said that LuaTeX has "better bidi support". What does that > mean, exactly? Should I be considering switching? > --scott > > On Dec 4, 2013 4:08 AM, "Keith J. Schultz" wrote: > Hi Scott, > > Am 03.12.2013 um 19:42 schrieb C. Scott Ananian : > > > > > But in the XeLaTeX/polyglossia/bidi output, the "soft space" weak > > directionality of the Unicode BiDi algorithm doesn't seem to be > > honored (or implemented?) and so the English article titles appear > > with the individual words in RTL order, which is a mess. Manually > > tagging the language of the article title is probably the Right thing, > > but infeasible for the entire wikipedia. > Well, without proper tagging you can not expect any system to > work properly or as expected! > For most entries a simple script should do the trick to add the > language tags to the article titles. > > Hope this helps > regards > Keith. > > > -- > 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] xetex and the unicode bidirectional algorithm.
Hi Scott, Am 03.12.2013 um 19:42 schrieb C. Scott Ananian : > > But in the XeLaTeX/polyglossia/bidi output, the "soft space" weak > directionality of the Unicode BiDi algorithm doesn't seem to be > honored (or implemented?) and so the English article titles appear > with the individual words in RTL order, which is a mess. Manually > tagging the language of the article title is probably the Right thing, > but infeasible for the entire wikipedia. Well, without proper tagging you can not expect any system to work properly or as expected! For most entries a simple script should do the trick to add the language tags to the article titles. Hope this helps regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Malayalam typesetting using XeLaTeX
Hi, Another command line tool on the Mac to find files is mdfind. See mdfind. regards Keith. Am 14.11.2013 um 01:16 schrieb NMPOST7 : > On 14/11/2013 01:08, Herbert Schulz wrote: >> >> Get the `Find Any File' application! No need to update the locate database, >> etc. > > Thank you Herb, > > Since I started on Linux in 1999, I find the commandline lovely. Since I am on > Mac now, I am back to GUI! > > Thank you just the same, I shall look up that application, too. > > BR > suren > > > > -- > 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 hyphen in xelatex
Hi All, There is one possibility which all seem to be all are over-looking! Direct input! - = - -- = – --- = — All characters are easily typed directly. (At least on the Mac) regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Zdenek, Am 07.08.2012 um 10:36 schrieb Zdenek Wagner : >> > Please do not mix engine and format. XeTeX does a few things i a > different way than TeX. In the LaTeX user's eyes the font loading is > different. It was not practical to modify the old LaTeX font loading > packages, therefore fontspec was developed. Due to encodings and other > reasons babel has to do a lot of additional things that are no longer > needed, therefore it was more practical to develop polyglossia. In > spite of all that the XeLaTeX syntax is exactly the same as the LaTeX > syntax. Briefly speaking, if I have a pure LaTeX code with default CM > fonts in OT1 encoding, I can process it by XeLaTeX without any > modification. Modifying a more complex LaTeX document for processing > by XeLaTeX is a matter of changing a few lines in the preamble but > they reflect just the engine change (TeX -> XeTeX). In principle LuaTeX is not different. There maybe just a little bit more code needed. At least there are provisions for handling of CM-fonts in LuaLaTeX. Though full support may not been implemented, yet. I have seen parts of code in the font loader. Actually, I would think it that hard of a task to do it if it done already. But, why and how things are done in LuaTeX is something I will discuss over on hier dev list. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Apostolos, Ulrike, All, I agree TFMs are outdated, but for being backwards compatible the functionality has to be in there. From what I have so far understood about LuaTeX is that the font loader can handle about all types of fonts running around, today. Even AAT-fonts. In other words there is a possibility to add ATSUI-functionality. If it is not there already. LuaTeX handles utf-8 natively and has support for older encodings, so no problem there either. One has to keep in mind that LuaTeX is still evolving. The developers have taken a very good approach: 1) get LuaTeX-proper working 2) add needed features 3) preserve backwards compatibility Missing features in the handling of eg. not so commonly used OT-features, is not necessarily an oversight on their part. Just, like the missing language support in TeX. So far, I do not see why LuaTeX can not have similar functionality as XeTeX. It will have a different syntax. just as XeTeX is different than LaTeX. To get there though one has to get involved. The more involved the better the chance that packages will be written so it is no longer needed to do the processing by hand. This is the TeX-way. regards Keith. Am 07.08.2012 um 09:06 schrieb Apostolos Syropoulos : > Ulrike Fischer a écrit: >> >> I understand you're concerned about future font support in LuaTeX, but >> technically the engine is little more than an extendable PDFTeX. Fonts >> follow that philosophy: TFM (with mapping to T1) fonts are supported >> as in PDFTeX, other formats must be loaded and processed by hand. Whether >> it's a good idea or not in that case I don't know, but it is definitely >> consistent. (Actually I do think it's a good idea, but I accept my >> opinion might be marginal.) >> > > Using TFMs and related technologies seems to me quite outdated. Personally, > I want to be able to use any font my system includes without having to do > fancy transformations. This and XeTeX's capability to natively process > UTF-8 source files were the factors that made me abandon "good", (really) > old TeX. BTW, TeX itself is consistent too, but it is definitely outdated. > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi All, No, Apostolos is right. Things got a little to OT. I apologize. I will next time listen to my inner feelings. regards Keith. Am 02.08.2012 um 17:38 schrieb Philip TAYLOR : > > > Apostolos Syropoulos wrote: > >> I fully agree with this remark. I suppose there are >> special lists for people interested in luaTeX and/or >> Context. > > but are there special lists for people interested in both > XeTeX /and/ LuaTeX (let us compare only like with like) ? > > If not (and I think not), then it is clear that a debate > involving both (as does the present debate) will take > place either on a XeTeX list or on a LuaTeX list or even > on both; as Professor Wedderburn would have said "There > is no alternative". > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Martin, I answering this as it goes for any software project. Those papers are nice and can help in general understanding, but they are to be of real use to a real programmer. Furthermore, if the are really relevant than then should be part of the source code distribution. There are different kinds of Documentation. TeX has a literate programming documentation style. In the TeX-world of today the source code documentation is minimal, where the API documentation is decent enough, if you know TeX. Then problem is that all that information in the papers should be in the source code!! Yes, it bloats the source code ten fold! But, all one needs to do is look at the header files and you understand what is being done. You do not need to understand the programming language, because it is all in the comments. Then the is the Program Specification. This is where you put in the rational, the design choices, the Graphics. What is all this good for you might ask. 1) Program varifiblity 2) Program mantainace 4) Porgram portabibilty 5) Cooperation during development It is all good software engineering. You do not need everything state of art. Yet, a little more natural language goes a long way. XeTeX could profit from this. As well as all other project. The bigger the project, the more people involved, the more technologies involved, the more important good documentation practices are needed. A decent programmer just needs a halfway decent specification to program anything. A programmer does not need to understand XeTeX, inorder to write the engine he needs to know what needs to go inside the engine. Lets take the XeTeX Font Manager and ATSUI. ATSUI was a comfortable way for handling the AAT-Font features. Know if it where documented in the source what data structures and which routine XeTeX used internally for handling the AAT-Font features It would not be hard to replace ATSUI with something else, because all you need to do is read the Advance True Type Font tables and put them into the internal data structures and maybe patch a routine or two. But, that is not documented anywhere. Come to think of it I believe, the problem is that there should have been another layer in there and XeTeX would not have the problem it has today with ATSUI So, my advice is now, who ever, when ever and another layer into the Font Manager of XeTeX, so that when the next pradigma change comes around the calls to ATSUI, or Core Text, or what ever only need to be updated and not the entire Font Manager for AAT-Fonts. And that was not a negative critic, just good advice form a programmers point of view. Am 02.08.2012 um 15:22 schrieb Martin Schröder : > 2012/8/1 Keith J. Schultz : >> As has been mentioned the source and programming rational behind >> LuaTeX is not documented, at least not publically. Even if one would >> do the programming their is no guarantee that the code will be used or >> allowed. > > There have been numerous papers and talks by the team. > Patches are always welcome. > > Everybody is free to take the code and fork the project. > > EOD: This is not the place for discussions about LuaTeX. > > Best > Martin > > > -- > 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]
Hi Again, I am now trying to grock LuaTeX otfload, that is ContTexts font loading system. >From what I have understood so far in order get things started is a >GDEF-feature and GPOS Lookup support in the font.loader and font-otf.lua. Do you know off hand, if these features are already implemented in Contexts or just not available in LuaTeX? Sorry, to everybody else I will this is getting OT(this is a XeTeX-List) and I will take this off list, if Arthur does not mind. reagrds Keith. Am 02.08.2012 um 04:40 schrieb Adam Twardoch (List) : > 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
Re: [XeTeX] resolution (was Re: The future of XeTeX)
Am 01.08.2012 um 18:56 schrieb Zdenek Wagner : > 2012/8/1 Keith J. Schultz : >> Hi Zdenek, >> >> [snip, snip] > No, microtype does not offer more glyphs, it offers glyph distorted in > many different ratios. Multiple Master Fonts would be able to solve it > in a better way but they were declared obsolete. There are just a few > MMF fonts distributed with Acrobat Reader but the development was > stopped years ago. Are you sure that you know what a glyph is. It is poosible to take the shape glyph and "distorted" this is then rendered. Factly, you are creating a different glyph. Or would would consider a straight line to be a circle. Certainly, you do not! In other words you are saying that the glph — is the same as o! >> To come back to Gutenberg, how Glyphs did he use? (No, I do not want an >> answer) Literally, serveral thousand if not millions. I leave it as a thought >> experiemnt to figure out why! >> > Approximately 2000 per page. They could be reused but not endlessly. > We use computer typesetting systems because production can be faster > and cheaper, not because Gutenberg was unable to do it. This is exactly, my point. Craftsmen can create fine details, yet the positioning and replication induces errors which is beyond the resolution of the details! Then, there is, also not just one craftsman involved. each adding his/her own personal touch. These variations gone beyond are higher than the resolution we have today. I do admit that these variations is what adds to the artist value. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Zdenek, I am perfectly, able to learn what I need to learn. I am perfectly able to program in almost any programming langauge. TeX is one that I can directly program in because I simple can grasp its philosophy. The biggest problem to all this at what is needed is so essential, that without the proper documentation of what has been the task becomes absolutely enormous. As has been mentioned the source and programming rational behind LuaTeX is not documented, at least not publically. Even if one would do the programming their is no guarantee that the code will be used or allowed. That is why nobody is willing or can actually step up to bat. Of course one could always spin off, then … … … regards Keith Am 01.08.2012 um 16:29 schrieb Zdenek Wagner : > The discussion clarifies what has to be done. It is useless to find a > person to do a job if you do not know what the job is and what the > person must know or learn in order to be able to do it. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] resolution (was Re: The future of XeTeX)
Hi Zdenek, you and William are missing my point. it does not matter. I believe you do not understand the full protential of modern typography, font format and the use of TeX. Glyphs need not be based on an particualar form in every situation. There are ways to have different Glyphs as Gutenberg used. All you need to do, is pick the right type of font and put the needed informtion in their. To be honest, I do not think one can find a truely complete Font. They are just a sub-set. microtype types to help enlarge teh feature set and thereby the available amount of Glyphs , but as with all things done programmitcally it is only as good as the programmer. To come back to Gutenberg, how Glyphs did he use? (No, I do not want an answer) Literally, serveral thousand if not millions. I leave it as a thought experiemnt to figure out why! Once, you have figured it out, my other argument will dawn on you. regards Keith. Am 01.08.2012 um 13:41 schrieb Zdenek Wagner : > 2012/8/1 William Adams : >> On Jul 31, 2012, at 6:02 PM, Keith J. Schultz wrote: >> >>> You are only partially correct. Yes, you can create very fine structures >>> off the glyphs. Yet, is only a part of the picture. >>> >>> You forget interword spacing and kerning. Gutenberg, could never match >>> the resolution of microtype. >> >> I give up. >> >> If one moves an element less than an imagesetter pixel dimension, how do I >> see that output in a useful fashion? >> > As a matter of fact, Gutenberg was able to do it better than > microtype. His glyphs were adapted, he had several versions of "m" > differing in width, kerning was also possible (look into old > textbooks, you will find how it was done). the main poit is thatthe > glyphs were designed to allow it, nowadays microtypography achieves a > similar rsult by distorting the characters. IMHO in the microtype > package the features are not used but abused and the result is often > uglier than the text typeset without it. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Zdenek, Do you know what a script is? XeTeX uses scripts! The the choice of a glyph is governed by a script.! Depending of the Font this is embedded into the Font itself or at least should be. Polyglossia offers another way of scripting. That it why I emphasize the port of Polyglossia to LuaTeX. Then Devagari would work for LuaTeX. The Developers of LuaTeX have stated openly that the personnally have no need for scripting and thereby given a very low-priority. regards Keith. Am 01.08.2012 um 15:54 schrieb Zdenek Wagner : [snip, snip] > LuaTeX can be considered a flavour of TeX thus if XeTeX can load a > font and use the glyphs as they are now and compose them to form a > word, I do not understand why a change in the script is needed. LuaTeX > is not able to form a word from Devanagari glyphs. MS Office, > OpenOffice, modern web browser can do it, so why should we discard the > very basics of Indic orthography a create the new one just because > nobody has implemented the Indic scripts in lua so far? And discard > all Indic fonts and create new ones that will suit the new > orthography? -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Zdenek, Am 01.08.2012 um 13:22 schrieb Zdenek Wagner : > 2012/8/1 Ulrike Fischer : >> Am Wed, 1 Aug 2012 12:30:52 +0200 schrieb Zdenek Wagner: >> >> Well you only confirm my impression: That quite a lot of scripts >> never felt the pressure put on us by the movable type printing. >> Western glyphs used in prints were greatly influenced by the >> technical possibilities and were adapted to what was possible. For >> me the idea that a printed document should look like "handwritten" >> is curious. >> > I do not state that it should look as handwritten but at least the > glyohs should have correct order and shape that is not too much > different (even in handwriting Devanagari has variants). With the > current version of luatex the correct order of glyphs cannot be > acheved. If I copy&past a text from Hindi Wikipedia and typeset it in > XeTeX, the result will be OK. If I do the same in luatex, the result > will be garbage. Why, because the language script is not support in LuaTeX!! -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Ulrike, Am 01.08.2012 um 12:13 schrieb Ulrike Fischer : > Am Wed, 1 Aug 2012 09:32:16 +0200 schrieb Keith J. Schultz: > >> From the simple user side. LuaTeX is about as easy as it gets. For >> most purpose I can teach you all you need to know how to use Lua >> for TeX in 2 hours! > > The problem are the people inbetween: The people who should develop > the code needed on top of the binary. As you could see in this > discussion the core problem currently is the handling of (open type) > fonts. And while the fontloader lua code in context (the source of > luaotfload) is quite advanced, it is undocumentated, has no sensible > api, and can change all the time in unexpected ways. Nobody outside > the context team can actually work on it and e.g add support for > scripts or correct bugs. That is probaly teh biggest turn off to LuaTeX. They should some people in as far as coding is concerned. The missing documentation is something I would call a cardinal offense. > (As an aside I think that one should not only put pressure on > xetex/luatex/open type engines to support all sorts of open type > features and scripts but also on some scripts to adapt a bit to the > computer age.) You have my vote, though I do not need them. Ignorance of the need for scripts or advance is one of the reasons we are in the TeX-mess we have. Knuth can no be blamed. Back then you programmed differently. Today, everything should be modular and extensible. > > > >> It's price for unicode support and using fontspec. But, >> those ancient packages using encodings should be a thing of the >> past, IMHO. > > Well in case of chess fonts they are not "a thing of the past". Not > because of some deficiency of luatex or xetex but because most > glyphs used e.g. by chessboards are not in unicode. You need some > local encoding to access them in a standarized way, and this means > you need the ability to reencode fonts. This should be possible with > luatex (and is in my eyes one of the advantage compared to xetex) > but can't be used due to the unclear state of the font loader. Please, do not get me wrong. I am not talking about the fonts! Just that if there is no necessity not to use unicode, unicode should used. Grüß Keith -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Am 01.08.2012 um 10:31 schrieb Zdenek Wagner : [snip, snip] > XeTeX is not a remedy to TFM deficiencies, it is again the remedy of > encoding deficiencies. It won't be that difficult to extend TFM but > implementation of Unicode and support for comlpex Arabic and Asian > scripts required complex rewrite. I am not to sure that the rewrite would be that hard! most of the work is already done!! TFM just needs to be adjusted. To over simplify. We can use the unicode support we have and map TFM to that. The rest … regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Zdenek, I believe well are pretty much inline with each other. Am 01.08.2012 um 10:48 schrieb Zdenek Wagner : > 2012/8/1 Keith J. Schultz : >> Hi Adam, >> >> Yes, LuaTeX is a evolving project, especially at the lowest level. >> Am 01.08.2012 um 02:54 schrieb Adam Twardoch (List) : >> >>> On 31.07.2012, at 13:02, Peter Dyballa wrote [snip, snip] >>XeTeX has is strength in typography, and support for languages, due >> to polyglossia. This is definitely missing in LuaTeX. > > This is not a principal problem. LuaTeX can still use babel and > polyglossia may be ported. I think that it makes use of > XeTeXinterchartoks for French, this has to be implemented in another > way but it can be solved. I know that one can use Babel. but Polyglossia is design for unicode supoort and handles non-latin languages, far better than Babel. [snip, snip] >> From the simple user side. LuaTeX is about as easy as it gets. For >> most purpose I can teach you all you need to know how to use Lua for TeX in >> 2 hours! >> > When trying to compile my first document written in Czech using UTF-8 > by lualatex it took me just a few minutes because from the user's > point of view fontspec is almost the same as in xetex. I was talking about using Lua, not writing TeX. > >>Did I say 2 hours!, Well, that is only for the simple user. For the >> TeX Macro Package developer things are harder. That it is, you have to learn >> how to manipulate TeX with Lua. >>Due to the complexity of TeX that is no easy task. Especially, since >> the only documentation is a reference manual, that does not explain >> anything! So, you either know low-level >>TeX or you are out of luck. >> > Yes, this is the problem. If I take the TeXbook, it explains chapter > by chapter all algorithms. It would be nice to have luatex > documentation that will explain, how all these algrithms may be > affected be lua, where the hooks are, what are the data structures. > The reference manual lists the hooks and provides syntax but I am > afraid that without reading the luatex source code I will not be able > to use them. How, true. One thing we should not forget is that LauTeX is not written in Lua. I believe they use C or one of its derivatives. Lua is just an extension to the binary code. The data structures should be pretty much the same as the ones in TeX. (just guessing, but it is my understanding). [snip, snip] regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Adam, Yes, LuaTeX is a evolving project, especially at the lowest level. Am 01.08.2012 um 02:54 schrieb Adam Twardoch (List) : > 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. XeTeX has is strength in typography, and support for languages, due to polyglossia. This is definitely missing in LuaTeX. Using low-level XeTeX is not at all that easy, if you do not know the TeX-way of doing things. > > 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. LuaTeX has a very small developer base and their goal is very high. a long needed rewrite of TeX. That is a complex task. From the simple user side. LuaTeX is about as easy as it gets. For most purpose I can teach you all you need to know how to use Lua for TeX in 2 hours! Did I say 2 hours!, Well, that is only for the simple user. For the TeX Macro Package developer things are harder. That it is, you have to learn how to manipulate TeX with Lua. Due to the complexity of TeX that is no easy task. Especially, since the only documentation is a reference manual, that does not explain anything! So, you either know low-level TeX or you are out of luck. I think you can throw almost standard LaTeX at LuaLaTeX and that should work. That, is everything that is not dependent a encoding. It's price for unicode support and using fontspec. But, those ancient packages using encodings should be a thing of the past, IMHO. > > 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. XeTeX is really, great and I had began to love it. I did what I wanted, unicode and use of system fonts. Well, LuaTeX can to that to thanx to fonspec. Furthermore, due to Lua I can do the things I always wanted to do with TeX for decades! > > 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. I was not happy with the choice of a "odd-ball" scripting language. But, due to its simplicity it seem to me to be the perfect choice. Very easy to learn. At least for getting things done. I have not gotten into its advanced features. Old school programming will do! Python would have been nice. But, the average LaTeX user would have extreme problems. Though from the programmers side it most likely would have made things easier. Yet, with the evolution going on with python you open up another can of worms. Sorry, for going OT here. If we could get more XeTeX and its advances into LuaTeX, them everybody would be very pleased. Time will tell. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] resolution (was Re: The future of XeTeX)
Hi William, You are only partially correct. Yes, you can create very fine structures off the glyphs. Yet, is only a part of the picture. You forget interword spacing and kerning. Gutenberg, could never match the resolution of microtype. Of course, the whole line could be done by hand, but how how exact could one get? regards Keith. Am 31.07.2012 um 19:38 schrieb William Adams : > On Jul 31, 2012, at 11:59 AM, Keith J. Schultz wrote: > >> except micro-type goe sway beyond Gutenbergs resolution! > > Sure, if one chooses to use sp to define such, but one defines in terms of an > em-square (the utility of the sp is that it forecloses on rounding issues). > > You're not going to have a useful value of less than a dot on an imagesetter > though, so 1/3600th of an inch is as small as it goes and 1/2400 or 1/2540 is > more typical, and w/ a graver one can take a curl off of a steel punch which > is that thickness or smaller, see Fred Smeijers, _Counterpunch: making type > in the sixteenth century, designing typefaces now_. > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Adrian, Xe(La)TeX will be around from quite some time. If I see things right many features are still being developed or expanded. Will it go away or die? Eventually, maybe. Who knows? I mean TeX is still around. regards Keith. Am 31.07.2012 um 22:14 schrieb Adrian Burd : > Is XeLaTeX/XeTex currently supported within the community? If not, is there a > good chance that it will go away/become incompatible/unusable in the future > (near or otherwise)? -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi Joachim, Am 31.07.2012 um 13:46 schrieb Joachim Trinkwitz : > Am 31.07.2012 um 11:06 schrieb Keith J. Schultz : > >> One of the reasons why I stopped using LaTeX was its lack of support for >> system fonts. >> Xe(La)TeX change all that. Yet, when I look at fontspec, I said what in all >> hell do I have to >> do all that (setting up all kinds of features, and God knows what). > > Most fonts, system, free or commercial, will function out of the box, without > fiddling with the fontspec options. Those are for the few exceptional cases > or for certain special needs like font variants, color etc. (OK, speaking > from the perspective of a user who don't need languages with non-latin > scripts …) The thing is if you read the manuals you wonder! I did not say that, but reading the maual you see you can set a font/family with all kinds of feature including the simple old bold and italic. I wonder if textit had gone away! No where is it stated in the manual that you do not need to set up the font families. I t is, also, not me many that I try to nudge into the TeX-world have the same experience. > >> Well that is another thing to keep in mind. For whom are all those features >> in Xe(La)TeX needed. >> A very elite group of people that understand typography and its use. Not, >> the average user. > > I tend to think this when people a whining over the lack of microtype support > in XeTeX, cause I don't believe each and every printed page need the > perfection of Gutenberg's Bible prints. But then, the majority of (La-/XeLa- > etc.)TeX users are just the types of writers which are passionate about > typography, at least much more than the 'average user' of other writing > systems … Good point, except micro-type goe sway beyond Gutenbergs resolution! regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Hi All, I will step in and offer my 2 Euro cents worth. First, we have to be careful not to mix oranges and apples. That is to say font formats , font feature sets, rendering engines and tex formats and tex engines. They are all different animals. 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. Is Core Text a alternative? Not, actually. Core Text does have some support for ATSUI, but it is not 1 to 1. I started to look into port XeTeX to 64-bit thinking it was a simple refactoring problem. I soon got lost in APIs and some ancient code. Furthermore, I soon found out that strictly from the source code and practically no knowledge of typography, I was lost. O.K. My problem. Yet, I did realize that it would be theorectically, possible, but the ease of use and known way would be lost. Another thing to keep in mind TeX et. al is not completely bachwards compatible either. Many older packages do not work or only work under certain circumstances. Lua(La)TeX helps in that packages can be easily written so that they do not interfere with other packages as they can be give their own namespace. In other words, you do not have to go through the standard TeX hoops to avoid conflicts, which makes programming packages far more easier. TeX is not easy to program and it takes years to understand the TeX way of thinking and programming. I have never been able to grock it and will never. Lua(La)TeX lets me avoid it, as the things I particularly want to are be more efficiently done in it. Expecting Xe(La)TeX code to run on anything, but Xe(La)TeX is utopical. Your source Xe(La)TeX, for texts, must be rewritten to match the other syntax. It is just like using the gnu compiler suites. They are not compatible. If the newer ones do not suite you, you are stuck with using deprecated code or learning to do things another way. TeX does support modern programming techniques and never will. Sure it has evolved to support modern technologies, yet it uses far to many crutches. It is like trying to program object oriented in C. Yes, that can be done, but alot more work, and in the end you end with C++, C#, or Objective-C. So why not learn these other languages from the start!? Lua(La)TeX is a move in this direction. Modernizing TeX!! The lack of features in Lua(La)TeX is just like the lack of feature in TeX, LaTeX, LaTeX2e, and Xe(La)TeX when they started out. Is math support finished in Xe(La)TeX? Is the support for all languages finished? No. Why? Well, just like everything in TeX you need people dedicated to developing them and an interest in doing so. Just like TeX decades ago. One of the reasons why I stopped using LaTeX was its lack of support for system fonts. Xe(La)TeX change all that. Yet, when I look at fontspec, I said what in all hell do I have to do all that (setting up all kinds of features, and God knows what). Do I really need to learn typography, now, to use typeset texts? From looking at the manuals yes. From my experience not that much. Well that is another thing to keep in mind. For whom are all those features in Xe(La)TeX needed. A very elite group of people that understand typography and its use. Not, the average user. Do not get me wrong, many of you are the backbone of using TeX and making it as easy as possible to use. As far as compatibility is concerned Xe(La)TeX is not even compatible with itself on different platforms! As someone already mentioned the 64-bit version do not support ATSUI on all systems. Furthermore, some platforms do not support ATSUI at all. On the otherside, in Lua(La)TeX you can produce pdf-output directly and inject it into the pdf. So, it should be possible to do anything, you need. I am not saying it will be easy and requiring inventing the wheel all over again. Soo, if more users do not switch to Lua(La)TeX and requesting features, the developers will not need feel the need to add low-level support for them or will those possibly interested step up to bat. It is like VHS and BetaMax. On will eventually win. The Users will decide. All others will be left with a outdated system that is deprecated. As far as Lua(La)TeX development is concerned. I am, personnaly, somewhat disappointed. I would have expected it to develop faster. Especially, documentation wise. Sure, there is a reference manual, but that does not help much, unless you are a TeXichian. Other, manuals to the Lua-interface are lacking in some respects, too. I have was chasing a bug(!) for more than a half a day. My code now works. So as you all can see it cuts both ways. I vote is to gradually switch to Lua(La)TeX. I believe that it can become the future. reagrds Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Two issues with bibliography
Hi there, Am 05.06.2012 um 17:44 schrieb proteus: > Apostolos Syropoulos writes: >> As far as I know "and" is not a Greek word!!! > >> In your opinion! Others, including the designer of biblatex, strongly >> disagree! > >> Just copy the relevant file into your working directory, adjust it >> to suit your own needs, and you are done! > > --- > > I suggest that A.S stops polluting the list with cantankerous, condescending > and derogatory replies. Interesting that you should be doing the same! Yet, I have to disagree. Furthermore, it is sad that your cites were so minimal and thereby misleading. 1) and is not a greek word. Yet it was written in a greek font. Thereby, indicating that something is very wrong with the coding of the source ! Therefore the triple exclamation. I would have used that, too!! 2) Designers or authors of packages, design things a certain way and have their reasons the way things should work and why. Just because the original posted is not happy is a different matter. 3) Apostolos, offers a solution. That is to hand code. Bibliographic work in TeX et al is not good at multi-lingual support. A well know fact! So, some tweaking is required. At least, I found his post to the point and helpful. Maybe, not what you expected or wanted. On the other side I can not say the same of your post. regards Keith. > > In the past I had similar problems with bilingual text exceeding the margins > and I was reading the topic with some interest to see if there is a solution. > > His disparaging remarks (punctuated with triple exclamation marks where a > single full stop would suffice) cause irritation and offer no help. > > > > -- > 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] XeLaTeX and SIunitx(in a way OT)
Thanx for the info. I was just curious because of the discussions about backward/"legacy" compatibilties with UTF. It would seem to me that them all "base" packages should be refractured to the point where the package/style file contains the if(engine) and loads then the appropriate files for them. Yes, this approach does have the big draw back that there is more code to maintain, yet it has the advantage the for older engines the code can be left alone and one can concentrate on the modern technologies. regards Keith. Am 14.05.2012 um 09:08 schrieb Bruno Le Floch: >> In a style file would say TeX barf if it contained utf-8 characters even if >> I have them in a conditional sothat the are not processed by the engine >> just parsed? > > I believe that it would be ok if you use the actual bytes ^^c3 and > ^^b5 in the file. > > The reason is that pdfTeX only makes (most) code points from 0 to 31 > invalid (?), and those only appear in the utf-8 encoding of the > Unicode code points 0 to 31, which you are probably not using in your > files (except 9, 10, 13, which are ok for pdfTeX). > > On the other hand, if you want to use the ^^ notation, for pdfTeX (set > up with the appropriate inputenc option) you'd need to use the eight > characters ^, ^, c, 3, ^, ^, b, and 5 (that'd give you à and µ in > [Xe/Lua]TeX), whereas for the other two engines you'd need either ^^b5 > or 00b5. In this last case of the notation, pdfTeX will > choke even if it appears in the unused branch of a conditional. > > Now, why would anyone use the ^^ notation? Because it is most robust > against encoding changes since we then only use ASCII characters. > Using utf-8 encoded characters directly is only good if you stick with > utf-8 (which I'd advise). > > So I'd say my impression is that the best is to use , but in a > separate file, loaded for the luatex or xetex engine. Three other > options: > > * Keep one file, work in a group, and use \catcode`\^^^=9 for the > pdftex engine before any appears. > > * Put the pdfTeX-specific commands first in the file, and > conditionally \ifpdftex \endinput \fi, then anyhing can appear later > in the file. > > * Use \char"00b5, which only works if your font is encoded in a > sensible way IIRC. > > Hope that helps (and is correct), > Bruno > > > > -- > 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] XeLaTeX and SIunitx(in a way OT)
Hi All,
I have a question.
In a style file would say TeX barf if it contained utf-8 characters even if
I have them in a conditional sothat the are not processed by the engine
just parsed?
regards
Keith
Am 14.05.2012 um 01:19 schrieb Ross Moore:
> Hi Ulrike, and Bruno,
>
> On 13/05/2012, at 11:05 PM, Ulrike Fischer wrote:
>
>> Am Fri, 11 May 2012 19:44:00 +0200 schrieb Bruno Le Floch:
>>
>>> I'm really no expert, but the siunitx package could include, e.g., µ
>>> as 00b5. This would not make pdftex choke when appearing in the
>>> false branch of an engine-dependent conditional.
>>
>> Using ^^..-notation is certainly a good idea in styles - regardless
>> of the engine - as it avoids encoding confusing.
>
> If by styles, you mean in a macro definition made within
> a separate style file, then I agree with you 100%.
>
> But ...
>
>> But it doesn't
>> solve the problem here as pdftex chokes if it sees more than two ^^:
>>
>
> ... this is not a good example to support this view.
>
>> \documentclass{article}
>> \begin{document}
>> 00b5
>> \end{document}
>
> The body of your document source should be engine independent,
> so this should look more like:
>
>
> \documentclass{article}
> \usepackage{ifxetex}
>
> \ifxetex
> \newcommand{\micronChar}{00b5}
> % handle other characters
> ...
> \else
> \if ...
> % handle other possibilities
> % e.g. ^^c2^^b5
> ...
> \fi
> \fi
>
> \begin{document}
> \micronChar
> \end{document}
>
>
> Better still, of course is to have the conditional
> definitions made in a separate file, so that similar things
> can all be handled together and used in multiple documents.
>
> You want to avoid having to find and replace multiple instances
> of the special characters, when you share you work with colleagues
> or need to reuse your own work in other contexts.
> Instead you should simply need to adjust the macro expansions,
> and all that previous work will adapt automatically.
>
>>
>>
>> ! Text line contains an invalid character.
>> l.9 ^^^
>> ^00b5
>> ? x
>>
>>
>> For pdftex you would have to code it as two 8bit-octect: ^^c2^^b5
>> But this naturally will assume that pdftex is expecting utf8-input.
>>
>> --
>> Ulrike Fischer
>
> 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] Babel
Hi Kiddies, I am getting a good laugh with this thread! Yes, there are caveats to the arguments. The important thing is that there is someone/ a team that is willing to improve the behavior of Babel and maybe teaching it some new tricks while not breaking it! The benefits may only be for a few of interest. The most important thing is that Babe lis not broken. Let's just sit back and is what happens! regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Overfull \hbox when using inline math scripts
Hi,
I would suggest putting a newline after the therorem title. Could right your
own command
for that.
Though it is a matter of style and taste.
regards
Keith.
Am 16.12.2011 um 02:55 schrieb Daniel Greenhoe:
> I have a rather long document involving mathematics that sometimes has
> the "Overfull \hbox" problem when I use inline mathematical scripts.
> Before I go hacking up the document with newline and \raggedright
> commands, is there any more elegant solution currently available?
> Below (see also attachment) is an example:
>
> \documentclass[12pt]{book}
> \usepackage{fontspec}
> \usepackage{unicode-math}
> \usepackage{geometry}
> \geometry{
> xetex,centering,twoside,noheadfoot,nomarginpar,
> paper=a4paper,margin=20mm,
> showframe
> }
> \setmainfont{texgyrepagella-regular.otf}
> \setmathfont{xits-math.otf}
> \setlength{\parindent}{0pt}
> \begin{document}%
> \thispagestyle{empty}%
> %\sloppy
> %\raggedright
> Theorem 1.1 (The Theorem That Has This Rather Long Title)
> Let the tuple $(X, Y, Z, A, B, C, +, x, -, !, \#)$
> be some useful mathematical structure.
> Then, \ldots
> \end{document}%
>
> Many thanks in advance,
> Dan
>
>
> --
> 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] polyglossia, right alignment is not correct
C'mon Phil, no problem. There must be a purpose in this madness. regards Keith. Am 13.12.2011 um 12:39 schrieb Philip TAYLOR: > Sorry, list : this was meant to go to Dominik, not everyone ... > ** Phil. > > Philip TAYLOR wrote: > >> Ah, Dominik, you mad mad "early adopter" : I shall be adopting >> TeX Live 2011 only when they announce that it is frozen in order >> to start work on TeX Live 2012 ! > > > -- > 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] (Xe)TeX Live after update: Upright font found, but not italic - Huh?
Hi Wolfgang, Eventhough you have things working now, I would still clean up you code or even templates! For example if you are using polyglossia you do not need babel. To my knowledge, babel is sufficient for german. regards Keith. Am 05.12.2011 um 12:11 schrieb Wolfgang Keller: > Hello, > > and thanks for your replies. > > In fact, I was using LyX, not an editor. And the root of the problem > was that I had told LyX in some configuration file to use \marginnote > instead of \marginpar, but an update of LyX has overwritten the > configuration file... > > Thanks, I should just have read the source exported from LyX more > carefully. > > Sincerely, > > Wolfgang > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] (Xe)TeX Live after update: Upright font found, but not italic - Huh?
I missed that! thought it was just font stuff. Anyway, after that he loads babel! I am almost sure first load font spec, polyglossia and then babel is likely to cause some weird side effects. regards Keith. Am 05.12.2011 um 08:58 schrieb Andy Lin: > Actually, he does load polyglossia. It's in the clump following xltxtra. > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] (Xe)TeX Live after update: Upright font found, but not italic - Huh?
Hi,
I am no expert, but
1) using XeTeX et al. you normally should not be using the fontenc
package!
2) In the example below you are using \usepackage with \makeatletter
I assume this will cause problems.
3) I would use polyglossia instead of babel, yet for german it is not
a must.
Am 04.12.2011 um 14:46 schrieb Wolfgang Keller:
> Hello,
>
> since last week, some update seems to have wrecked something in my TeX
> Live installation. The example document (fo testing, you need the
> Libertine typeface) below:
>
> %% LyX 2.0.2 created this file. For more info, see http://www.lyx.org/.
> %% Do not edit unless you really know what you are doing.
> \documentclass[10pt,ngerman]{scrartcl}
> \usepackage[T1]{fontenc}
[1] remove above line
> \usepackage{geometry}
> \geometry{verbose,tmargin=3cm,lmargin=5.5cm}
> \usepackage{fancyhdr}
> \pagestyle{fancy}
> \setlength{\parskip}{0pt}
> \setlength{\parindent}{0pt}
>
> \makeatletter
> %% User specified LaTeX commands.
> \usepackage{fontspec}
[2] did you forget \makeatother before the above line?
I believe, also, that font spec should be loaded after babel!!
> \usepackage{xltxtra}
> \setmainfont[Mapping=tex-text, ExternalLocation,
> UprightFont=LinLibertine_R.otf, BoldFont=LinLibertine_RB.otf,
> ItalicFont=LinLibertine_RI.otf, BoldItalicFont=LinLibertine_RBI.otf,
> Numbers={Proportional,OldStyle}]{Libertine} \setsansfont
> [Mapping=tex-text, ExternalLocation, UprightFont=LinBiolinum_R.otf,
> BoldFont=LinBiolinum_RB.otf, ItalicFont=LinBiolinum_RI.otf,
> BoldItalicFont=LinBiolinum_RI.otf, Numbers={Proportional,OldStyle},
> Scale=MatchLowercase]{Biolinum} \usepackage{textcase} \usepackage
> {scrpage} \renewcommand{\headrulewidth}{0pt} \usepackage{xkeyval}
> \usepackage{polyglossia} \usepackage{marginnote} \reversemarginpar
> \renewcommand*{\marginfont}{\rmfamily\itshape} \setlength
> {\marginparwidth}{1.67\marginparwidth}
>
> \AtBeginDocument{
> \def\labelitemi{\Libertine{\namedglyph{bullet}}}
> \def\labelitemii{\(\circ\)}
> \def\labelitemiii{\(\diamond\)}
> }
>
> \makeatother
>
> \usepackage{babel}
[3] I would use polyglossia
> \usepackage{xunicode}
> \begin{document}
> \marginpar{Randnotiz}Text
> \end{document}
>
> generates this warning:
>
> LaTeX Warning: Marginpar on page 1 moved.
>
>
> LaTeX Font Warning: Font shape `EU1/Libertine(0)/m/sl' undefined
> (Font) using `EU1/Libertine(0)/m/n' instead on input line
> 41.
>
> [1
>
> ] (./Test202.aux)
>
> LaTeX Font Warning: Some font shapes were not available, defaults
> substituted.
>
> and the attached PDF output. The marginnote text should be
> vertically aligned with the body text and in italic.
>
> Could anyone give me a hint what might be broken?
>
> TIA,
>
> Sincerely,
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] tabular in footnote
Hi John,
The philosophers can think, but have poor writing habits and style IMHO!
Yet, that is a tradition. ;-))
regards
Keith.
Am 04.12.2011 um 13:40 schrieb John Was:
> Hello
>
> I use plain XeTeX, and thanks to scholars of ancient philosophy who like to
> have huge footnotes (sometimes including tabular matter or extensive workings
> in formal logic) I do sometimes have to specify that certain groups of lines
> cannot split between pages. Within tabular I just have \noalign{\nobreak}
> between the lines of the table that aren't to be split, and if a whole table
> was to be regarded as non-splittable I suppose I would put it all within
> vertical box: \vbox{TABLE IN HERE}.
>
> Wordy commands can always be reduced for quickness in typing, for example:
>
> \def\nbr{\noalign{\nobreak}} would let you type \nbr between tabular lines
> that aren't to be split.
>
> Do TeX primitives like that not work in LaTeX?
>
> Best wishes
>
>
> John
>
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] tabular in footnote
Hi Dan, O.K. Having references in the footnotes is quite normal. Use to do all the time. The only problem I have is that I see no reason for fancy alignment, but that be just me. I do not no if this helps, but you might try using math mode. Another, possibility I see is using Tikz/PGF. Of course, you should create a command like \myrefernce for easy typing or even \myfootnote. regards Keith. Am 04.12.2011 um 12:51 schrieb Daniel Greenhoe: > Hi Keith, > > On Sun, Dec 4, 2011 at 6:01 PM, Keith J. Schultz wrote: >> Most writers show poor style by stuffing all kinds of information in the >> footnote > > Thank you for your honest feedback. The purpose of the tabular > footnotes is for citation information. I like verbose citations; I do > not like seeing a reference with just a [1] and then I have to fish > around in the nether regions of the book to get any clue as to what > reference it refers to. Rather for each, say, theorem, I like to put > on the same page (or close to the same page) as where the theorem > occurs > 1. multiple references for that one theorem (recent and old/original > if possible) > 2. reference information that is verbose enough to contain an > author, a title, and a year (normally with additional info available > in the Bibliography) > > I realize this style is not standard in the book industry, but I like > it. And I think not having it this way may in part be a vestige of > out-dated technology (e.g. typesetting with a simple typewriter). > > Thus, I often have several lines (one line per reference) for a single > footnote. And I implement this using a tabular environment. I think > tabular environments are a good mechanism for aligning material > neatly. > > Dan > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] tabular in footnote
Hi Dan,
Though, you problem is interesting, but I can believe you have this
problem.
You do realize that a footnote in general is not intend to contain this kind of
information. Even though it may be possible in TeX, et al.
Most writers show poor style by stuffing all kinds of information in the
footnote
because they do not take the time to properly integrate what the have to say
into the main
text.
But, you can do whatever you want.
regards
Keith.
Am 04.12.2011 um 00:31 schrieb Daniel Greenhoe:
> When I put a tabular in a footnote, the tabular often is extended
> outside the text area. Besides placing a newline directive after the
> tabular environment, is there anything I can do to prevent this
> behavior? That is, how can I best ensure that tabulars in a footnote
> get typeset completely within the text area? Here is an example:
>
> \documentclass[12pt]{book}
> \usepackage[xetex,a4paper,noheadfoot,nomarginpar,margin=20mm,showframe]{geometry}
> \begin{document}%
> xyz\footnote{%
>%\raisebox{2.5mm}{
> \begin{tabular}[t]{|l|}
> \hline
>abc\\
>def\\
>ghj\\
>klm\\
>\hline
> \end{tabular}%\\
> %}%
>}
> xyz\footnote{%
>%\raisebox{2.5mm}{
> \begin{tabular}[t]{|l|}
> \hline
>abc\\
>def\\
>ghj\\
>klm\\
>\hline
> \end{tabular}%\\
> %}%
>}
> \end{document}%
>
> Many thanks in advance,
> Dan
>
>
> --
> 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] Diacritics in color
Hi Khaled, I am afraid you are completely misconceived about what the subject matter is here. 1) adding a diacritic mark(glyph) is composing a a glyph, You are able to output it on its own. 2) There is a difference between the glyph ä and adding the diactirc mark of umlaut to an a. a) in the first case you can use two different colors because it is one glyph. b) in the second you can use two different colors because you two glyph in order two compose the ä glyph. So we are talking about composed glyphs whether you realize it or not. regards Keith. Am 30.11.2011 um 13:56 schrieb Khaled Hosny: > On Wed, Nov 30, 2011 at 11:10:11AM +0100, Keith J. Schultz wrote: >> Hi All, >> >> I jump back in. I will cite anybody because what has been said is correct. >> >> But, >> >> 1) trying to compare a browser, XeTex engine and LuaTeX will not help >> as they have different methods of composing their output. >> That is how they compose and position their glyphs. > > As far as OpenType processing is concerned they all should give the same > result, else there is a bug somewhere. > >> 2) Most important a composed Unicode glyph is supposed to be just one >> color!! > > No one talked about composed glyphs (certainly not the OP), it was just > a marginal and unrelated issue to the problem being discussed; coloring > combining marks without breaking OpenType mark positioning. > >> 3) Once you start using color a Unicode composed glyph you no longer >> are positioning >> a single composed glyph, but two or more glyphs. > > So? Again, coloring components of composed glyphs is not what is being > discussed here. > >> 3.a) color designed in TeX at.al is designed be applied to a box and >> not glyphs!! > > I've hard time understanding what this mean or how the difference, if > any, is material. AFAIK, TeX knows nothing about color, it handled just > like any other driver special which TeX makes no effort to interpret not > to mention "applying" it. > >> The question remains how to position the composed glyphs and where and how >> the color attribute >> is added to the output. >> >> There are therefore two solutions: >> 1) The Tex way: >> create a macro to compose the glyph and do the positioning and >> coloring. >> >> 2) The developer way: >> change the engine so that it firsts generates the composed >> glyph and then goes back >> and then applies color to the different glyphs. > > 3) The post-2000s way; use/build an OpenType font with proper combining > mark positioning and apply the colors to individual glyphs à la what > FireFox/LuaTeX and may be many other does. > > 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
Re: [XeTeX] Diacritics in color
Hi All, I jump back in. I will cite anybody because what has been said is correct. But, 1) trying to compare a browser, XeTex engine and LuaTeX will not help as they have different methods of composing their output. That is how they compose and position their glyphs. 2) Most important a composed Unicode glyph is supposed to be just one color!! 3) Once you start using color a Unicode composed glyph you no longer are positioning a single composed glyph, but two or more glyphs. 3.a) color designed in TeX at.al is designed be applied to a box and not glyphs!! The question remains how to position the composed glyphs and where and how the color attribute is added to the output. There are therefore two solutions: 1) The Tex way: create a macro to compose the glyph and do the positioning and coloring. 2) The developer way: change the engine so that it firsts generates the composed glyph and then goes back and then applies color to the different glyphs. Such a change most likely will not happen for XeTeX, as the development has staled or if you wish is frozen. LuaTex is still under development and can be adjusted. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XETEX cannot access OpenType features in PUA?
Hi Everybody,
I have been loosely following this thread.
>From my lay point of view. Using two different colors can
work unicode for composing the output in (Xe)Tex.
>From my simplistic view, it would be just a having a two color
"T" where the top cross should be red and the rest black.
(Xe)Tex uses boxes. one for each color. So, once you use a different
color those glyphs are set in a box of their own. This is a feature
of (Xe)TeX.
So, naturally, using different colors for composed characters/glyphs will have
to break anything unicode wants to do. You have to do it in (Xe)Tex.
As comparing firefox to XeTeX is like comparing apples to oranges, they
use completely different layout engines.
One should be aware of the fact that XeTeX uses unicode for composing
glyphs during input, yet the it is processes further before it is output in
a completely different form. That is the way XeTeX is designed.
So the only solution would be to use a command like \twocolor{c1,
c2}{glyph1}{glyph2}
or the like.
regards
Keith.
Am 27.11.2011 um 23:49 schrieb Aleksandr Andreev:
> mskala writes:
>
>>> I've been watching this discussion with interest, having had similar
> problems.
>
> Basically, after I added cyrillic and latin to the subtables and
> removed the color, the OpenType features started working.
>
> Now, for the color. Searching this list reveals that there was some
> discussion a while back about coloring vowels in Hebrew text
> (basically, an identical problem). Judging from the discussion here:
> http://tug.org/mailman/htdig/xetex/2007-July/006987.html it appears to
> be impossible. The solution proposed was to print the text twice --
> first the Hebrew consonants in black and then overprint the vowels in
> color. I wouldn't call that a solution, but rather a workaround.
>
> It appears that XeTeX colors are handled by inserting pdfliteral nodes
> around colored items, which breaks the access to GPOS.
>
> Unless there's been some work on this issue since 2007, it appears
> that I will need to look for a different way of typesetting my
> document.
>
> A
>
>
> --
> 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] (OT) Re: TeX in the modern World. (goes OT) Was: Re: Whitespace in input
Alahs, the amoeba turning machine was a beauty of the time. ;-)) Am 20.11.2011 um 20:27 schrieb Dominik Wujastyk: > IBM golf ball "Selectric"? > > Luxury! > > My university used to beat me over the head with an abacus made of stone for > 25 hours a day, before sending me to do data entry with a chisel at the back > end of a cave lit only by burning data-cards, while solving Eulerarian > equations for fluid motion using machine-code programming on the ribs of a > dead antelope. Try telling that to the kids today! Will they believe you? > > > > On 19 November 2011 09:27, Philip TAYLOR wrote: > > > Keith J. Schultz wrote: > >Me I am almost 50 and have been around computers since the 80s. >First was a Apple IIe, at the university we used a main frame. > > My first computer was a Clary 404, with 8K of magnetic core memory, > a magnetic card reader and/or teletype as input device, and an > IBM golf ball "Selectric" typewriter for output. A 3rd-year > undergraduate, working under my supervision, wrote a chess end-game > solver that would run on this machine and solve end-game problems > in reasonable time. I wonder how many programmers today could do > the same with 125 000 times as much memory (1Gb) ? > > ** Phil. > > > > -- > 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] Whitespace in input
Am 19.11.2011 um 13:51 schrieb Zdenek Wagner: > 2011/11/19 Keith J. Schultz : > >>As for getting junk when copying unicode, just copy between to text >> using different fonts, where one font does >>not contain the glyph. >> > When performing copy&paste or text search in PDF, I am not interested > in glyphs but in characters. I do not care what glyphs will be > displayed. If I copy the text to OpenOffice, I can change the font > later and if the codepoints were transferred correctly, I will see the As you say if transferred correctly! > text (it was true even with OpenOffice 1.x, I tried many years ago). > If I copy the text to gedit, ontconfig will automatically find a font > for displaying the characters not present in the current font. I still > have to read the fontconfig manual in order to find how to configure > its searching algorithm. Arabic fonts may be a problem especially if > you wish to use Arabic, Persian and Urdu. Now I know that I have to > force fontonfic to select automatically SIL Scheherezade because it > contains all characters. I can thus use both U+0643 and U+06A. When > writing Akbar, I can write it both in Arabic and in Urdu/Farsi [snip, snip] >> The only advise I can give is choose your tools wisely. >> regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
OUCH! I have been hit by a veteran truck drivers truck. ;-)) I concede! I am curious if many still know what a XX-bit word is. Is that term even still used? Turn Unicode needs to be clean up it has become to fragmented. regards Keith. Am 19.11.2011 um 09:39 schrieb Philip TAYLOR: > > > Keith J. Schultz wrote: > >> I do not think anybody disputes the fact that characters are not glyphs. >> >> The confusion arises that a character in CS is well defined and has a >> history. >> To be more exact it is just one byte in size so that there can be only >> 256 characters. > > Sorry, Keith, this is patently untrue. Replace "is" by "was once" and > you get a little closer to the truth, but you still completely ignore > issues such as the difference between (say) EBCDIC and ASCII. CDC machines > used a 60-bit word, and one character was six bits, not eight. And before > the advent of the extended character set, a character consisted of seven > bits plus a parity bit, thus yielding at most 128 characters of which > 32 were reserved for control functions. > >> The average user considers a glyph to be the same as a "letter" and >> thereby a character. > > It is rarely safe to believe that one knows what the average user thinks ... > >> Now, in order to process the glyphs with a computer it must be >> decomposed back to unicode. > > But one rarely, if ever, "processes glyphs"; the glyphs are the end result, > not the input. Glyph processing does become necessary in languages such > as Arabic, where context has a major impact on the way in which the > individual glyphs are presented, but in Western languages the nearest we > get to "glyph processing" is in the formation of ligature digraphs. > >> How well this is done depends of the system its self. If the system is >> not fully unicode aware and >> implements in properly then there will be problems. What adds to the >> complexity of the problem is that >> not all fonts used for displaying unicode contain all code points, >> Thereby, creating your many to many >> decomposition. >> >> As for getting junk when copying unicode, just copy between to text >> using different fonts, where one font does >> not contain the glyph. >> >> The only true way to master this problem is if the computer world would >> go completely full unicode with >> fonts support the full unicode code set! > > I personally hope that this does not happen, and that before then > we have an "Omnicode consortium" to review the mistakes of Unicode > and to address them in a future, more orthogonal, more consistent, > specification. > > Philip Taylor > > > -- > 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] Whitespace in input
Hi Zdenek, I do not think anybody disputes the fact that characters are not glyphs. The confusion arises that a character in CS is well defined and has a history. To be more exact it is just one byte in size so that there can be only 256 characters. Unicode has change all this. and we have a unicode character which is of different sizes depending on the unicode encoding used. It gets even hairier as in unicode several unicode characters can be combined (composed). the result to be output is known as a glyph! The average user considers a glyph to be the same as a "letter" and thereby a character. Now, in order to process the glyphs with a computer it must be decomposed back to unicode. How well this is done depends of the system its self. If the system is not fully unicode aware and implements in properly then there will be problems. What adds to the complexity of the problem is that not all fonts used for displaying unicode contain all code points, Thereby, creating your many to many decomposition. As for getting junk when copying unicode, just copy between to text using different fonts, where one font does not contain the glyph. The only true way to master this problem is if the computer world would go completely full unicode with fonts support the full unicode code set! That is impractical for the time being. The only advise I can give is choose your tools wisely. regards Keith. Am 18.11.2011 um 23:51 schrieb Zdenek Wagner: > 2011/11/18 maxwell : >> On Fri, 18 Nov 2011 13:52:56 +0100, Zdenek Wagner >> >> wrote: >>> 2011/11/18 Philip TAYLOR : Is it safe to assume that these "code listings" are restricted to the ASCII character set ? If so, yes, spaces are likely to be a problem, but if the code listing can also include ligature- digraphs, then these are likely to prove even more problematic. >>> If the code listing is typeset in a fixed width font, it is usually no >>> problem. I copied a few code samples from books in PDF, most of them >>> were typeset by TeX. If I want to copy text in Devanagari, it is >>> almost impossible. >> >> Besides TeX, Dr. Knuth also invented Literate Programming. In our own >> project, we use LP to extract the code listings from the original source >> code, rather than from the PDF. One advantage is that in addition to the >> re-ordering at the character level (mentioned in part of Zdenek's email >> that I didn't copy over), this allows re-ordering at any arbitrary level, > > This is a demonstration that glyphs are not the same as characters. I > will startt with a simpler case and will not put Devanagari to the > mail message. If you wish to write a syllable RU, you have to add a > dependent vowel (matra) U to a consonant RA. There is a ligature RU, > so in PDF you will not see RA consonant with U matra but a RU glyph. > Similarly, TRA is a single glyph representing the following > characters: TA+VIRAMA+RA. The toUnicode map supports 1:1 and 1:many > mappings thus it is possible to handle these cases when copying text > from a PDF or when searching. More difficult case is I matra (short > dependent vowel I). As a character it must always follow a consonant > (this is a general rule for all dependent vowels) but visually (as a > glyph) it precedes the consonant group after which it is pronounced. > The sample word was kitab (it means a book). In Unicode (as > characters) the order is KA+I-matra+TA+A-matra(long)+BA. Visually > I-matra precedes KA. XeTeX (knowing that it works with a Devanagari > script) runs the character sequence through ICU and the result is the > glyph sequence. The original sequence is lost so that when the text is > copied from PDF, we get (not exactly) i*katab. Microsoft suggested > what additional characters should appear in Indic OpenType fonts. One > of them is a dotted ring which denotes a missing consonant. I-matra > must always follow a consonant (in character order). If it is moved to > the beginning of a word, it is wrong. If you paste it to a text > editor, the OpenType rendering engine should display a missing > consonant as a dotted ring (if it is present in the font). In > character order the dotted ring will precede I-matra but in visual > (glyph) order it will be just opposite. Thus the asterisk shows the > place where you will see the dotted circle. This is just one simple > case. I-matra may follow a consonant group, such as in word PRIY > (dear) which is PA+VIRAMA+RA+I-matra+YA or STRIYOCIT (good for women) > which is SA+VIRAMA+TA+VIRAMA+RA+I-matra+YA+O-matra+CA+I-matra+TA. Both > words will start with the I-matra glyph. The latter will contain two > ordering bugs after copy&paste. Consider also word MURTI (statue) > which is a sequence of characters > MA+U-matra(long)+RA+VIRAMA+TA+I-matra.
[XeTeX] (OT) Re: TeX in the modern World. (goes OT) Was: Re: Whitespace in input
Hi Arthur, No problem. you have my permission. I was just judging from his comments. No offense meant. Me I am almost 50 and have been around computers since the 80s. First was a Apple IIe, at the university we used a main frame. regards Keith. P.S. Want a signed version. regards Keith. Am 18.11.2011 um 14:57 schrieb Arthur Reutenauer: > On Fri, Nov 18, 2011 at 10:16:31AM +0100, Keith J. Schultz wrote in > reply to Ross Moore: >> You are probably a little young to know this, but TeX's original output >> format was a dvi file. > > I think I'll have this one framed and sent to Ross for his next > birthday. > > Arthur > > > -- > 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] Whitespace in input
Hi Philip, No, it is not XeTeX specific. Like I have mentioned, I am not a TeXchian. I have never been able to grok the low level TeX way of doing things. I could probably do now, but there are others more apt to the task than I. I have mention I would first put a NLP-layer in TeX et al. before the typesetting starts to kick end. In other words, handle the language and encodings first and then typeset. But, that is not how (Xe)TeX is designed. regards Keith. Am 18.11.2011 um 08:51 schrieb Philip TAYLOR: > > > Keith J. Schultz wrote: > >> The crux of of the problem is in (Xe)TeX's parsing algorithm. I never liked >> it >> and personally I have many problems it. > > Is this XeTeX-specific, Keith, or do you also dislike > TeX's parsing algorithm ? And what is it that you > dislike, and how would you propose that it be improved ? > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] TeX in the modern World. (goes OT) Was: Re: Whitespace in input
Hi All, Sorry, I go OT here, but in order to debate it is necessary. Please forgive. I have to side more with Philip. What most are forgetting is what (Xe)TeX is intended for. It is for most a typesetting program(you do mention this below). It was not designed to handle different languages or actually truly do wordprocessing in the modern sense. Due to the power of the TeX engine, it evolved to deal with different languages and newer output methods and encodings. The problem with TeX that the basic engine has not been redesigned to handle these new developments well. The internals need to be completely revamped. Am 17.11.2011 um 20:36 schrieb Ross Moore: > Hi Phil, > > On 17/11/2011, at 23:53, Philip TAYLOR wrote: > >> Keith J. Schultz wrote: >>>> >>>> You mention in a later post that you do consider a space as a printable >>>> character. >>>This line should read as: >>> You mention in a later post that you consider a space as a >>> non-printable character. >> >> No, I don't think of it as a "character" at all, when we are talking >> about typeset output (as opposed to ASCII (or Unicode) input). > > This is fine, when all that you require of your output is that it be visible > on > a printed page. But modern communication media goes much beyond that. > A machine needs to be able to tell where words and lines end, reflowing > paragraphs when appropriate and able to produce a flat extraction of all the > text, perhaps also with some indication of the purpose of that text (e.g. by > structural tagging). I would agree with you, but TeX was not designed as a communications program, it was designed for creating printed media. Furthermore, it may be desirable in the Modern World to have every programs out used as input for another program. This ideal is utopia. If you need the output from one program(media) to another then you will need a intermediate program/filter in order to reformat/convert the differences. As with all types of communication there will be structures missing/lacking in the other system. So a one to one conversion will not be possible. You will need to use some kind of heuristics or in modern terms intelligence. > > In short, what is output for one format should also be able to serve as input > for another. This assertion is completely idealistic. Then again, it is true. It is possibly, today, to design a system that goes from audio, to TeX, to printed documents to audio again. Yet, you will need a lot of effort and most likely the results will be far from perfect. Though it is workable and require considerable resources. > > Thus the space certainly does play the role of an output character – though > the presence of a gap in the positioning of visible letters may serve this > role in many, but not all, circumstances. This depends on what you are outputting. For a printed page and is consumed by a human it goes not matter, because humans do not process space characters just space, and they even at times ignore them completely, because it is irrelevant for their natural language processing. For computers on the other hand the use of a space character can be very relevant. In the early days of TeX and LaTeX I have know people to create their e-mail with TeX. So you can see TeX is capable of outputting character based output. Furthermore, TeX could be used to produce any form of character based formats as its output. > >> Clearly >> it is a character on input, but unless it generates a glyph in the >> output stream (which TeX does not, for normal spaces) then it is not >> a character (/qua/ character) on output but rather a formatting >> instruction not dissimilar to (say) end-of-line. > > But a formatting instruction for one program cannot serve as reliable input > for another. > A heuristic is then needed, to attempt to infer that a programming > instruction must have been used, and guess what kind of instruction it might > have been. This is not 100% reliable, so is deprecated in modern methods of > data storage and document formats. Are you not contradicting yourself here! See above. > XML based formats use tagging, rather that programming instructions. This is > the modern way, which is used extensively for communicating data between > different software systems. True it is used, for communicating data. Yet, you are misconceived in thinking that it truly solves any of the problems involved different data types or content! You can get a parse tree of the data, yet if a program can not understand or process the data/content it is useless. Agreed the XML file contains i
Re: [XeTeX] Whitespace in input
Hi Pihilip, Thoughout, my programming life and experience I have learned that internal structure means nothing, as long as the result is correct when it comes out. As you rightfully point out the problem lies inside how TeX internally handles space characters when adding them to its internal structure. The fact is that initially, TeX was not designed to handle modern typesetting well. (Xe)TeX's internals are partially quite outdated. It is possible to to handle all this "new" type of spaces in (Xe)TeX, yet it is quite awkward and you have to be a TeXchian to do it properly. My personal opinion is that TeX et al. has to be revamped completely. Ideally, it should get a natural language parser as a front end and the typesetting module as its back-end for its output. Yes, I know this would not be TeX any more and require a complete different structure of the TeX eco-system. Language modules and the like. I you care to discuss this we cam back channel as it would be to OT, here. regards Keith. Am 17.11.2011 um 20:56 schrieb Philip TAYLOR: > Ross, I do not dispute your arguments : I was answering > Keith's question in an honest way. I (personally) do not > think of a space in TeX output as a character at all, > because I am steeped in TeX philosophy; but I am quite > willing to accept that /if/ the objective is not to > produce output for the sake of output, but output for > subsequent processing as input by another program, then > there /may/ be an argument for outputting a space as a > variable-width glyph. > > However, I do think that what appears in the output stream > is a secondary consideration; far more important (IMHO) is > how we represent that space /within XeTeX/. There is, I am > sure, not a suggestion on the table that we start to treat > a conventional space in XeTeX other than as TeX has traditionally > treated it, and therefore the real question is (to my mind), > "do we adopt an extension of this traditional TeX treatment > for non-breaking space, thin-space, and any of the other > not-quite-standard spaces that Unicode encompasses, or do > we look for an alternative model which /might/ be glyph- > or character-based ?". -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
Hi Philip, We are basically are following the same lines. TeX is foremost a layout program based standard "printers" methology.where the space character is white space and not a glyph. We actually, do have to differentiate between the two in discussions. The crux of of the problem is in (Xe)TeX's parsing algorithm. I never liked it and personally I have many problems it. regards Keith. Am 17.11.2011 um 13:53 schrieb Philip TAYLOR: > > > Keith J. Schultz wrote: >> >> Am 17.11.2011 um 11:26 schrieb Keith J. Schultz: >> >>> O.K. >>> >>> You mention in a later post that you do consider a space as a printable >>> character. >> This line should read as: >> You mention in a later post that you consider a space as a >> non-printable character. > > No, I don't think of it as a "character" at all, when we are talking > about typeset output (as opposed to ASCII (or Unicode) input). Clearly > it is a character on input, but unless it generates a glyph in the > output stream (which TeX does not, for normal spaces) then it is not > a character (/qua/ character) on output but rather a formatting > instruction not dissimilar to (say) end-of-line. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
Am 17.11.2011 um 11:26 schrieb Keith J. Schultz: > O.K. > > You mention in a later post that you do consider a space as a printable > character. This line should read as: You mention in a later post that you consider a space as a non-printable character. > I do disagree, in the sense that, even though you actually can not see how > many spaces are in a run, > that it does have a size and thereby does have a fixed visual affect. > > I do agree with you, that a space character should, in good layout, be > changed to a space of white to > accommodate good line breaking. So it is not truly a printable character in > text layout. > > Though, I do prefer inter character spacing a preferable method to achieve a > more aesthetically look. > > Know more to point. > > Often enough there are conventions that one has to follow concerning the > wrapping of words. Most > prominent Names. > > As an example I will use my name Keith J. Schultz. (Yes, this is not the best > example and (Xe)Tex has ways > of getting around this) Names should not be wrap or should there not be > unnecessary space between the parts. > Generally, it is O.K. to wrap/line break after the "J.", but not between > Keith and "J." so I need a non breaking space between > them, also you do not want different space between "Keith", "J." and > "Schultz", yet not the same space as used between other > words of the line. If the "J." bothers you use "Johan" instead. The same is > true of Mrs. Smith. > > So the use of a non breaking space with given size is advisable for input. Of > course, what TeX et al. should output is debatable > and it wreaks havoc with TeX's line breaking algorithm. > > It is often hard to get the desired results. But, the way TeX works this will > always be a problem. > Yet, when I enter a non-breaking space that is what I want and more often > than not a space of > fixed size across the board. > > regards > Keith. > > > > > Am 15.11.2011 um 12:09 schrieb Philip and Le Khanh: > >> >> >> Keith J. Schultz wrote: >> >>> A non.breaking space is to me a printable character, in so far that >>> it is important and must be used to distinguish between word space, et all. >> >> If, for you, "[a] non.breaking space is a printable character", then >> presumably that character must be taken from some font. If you take >> a character from a font, it will have a size, and although it can be >> combined with kerning rules to adjust its position w.r.t. adjacent >> characters, the logic for this is fairly restricted. In particular, >> it cannot take into account the amount by which TeX is seeking to >> expand or contract spaces on the current line in order to achieve >> optimal paragraphs. So in your model of the ideal universe, non-breaking >> Unicode spaces would not behave as do conventional >> TeX non-breaking spaces (which /do/ expand and contract to assist >> in TeX's line-breaking), nor would they conform to their Unicode >> definition where their decomposition is defined as : >> >> SPACE (U+0020) >> >> I wonder if you would like to discuss these points ? >> >> Philip Taylor > > > > > -- > 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] Whitespace in input
O.K. You mention in a later post that you do consider a space as a printable character. I do disagree, in the sense that, even though you actually can not see how many spaces are in a run, that it does have a size and thereby does have a fixed visual affect. I do agree with you, that a space character should, in good layout, be changed to a space of white to accommodate good line breaking. So it is not truly a printable character in text layout. Though, I do prefer inter character spacing a preferable method to achieve a more aesthetically look. Know more to point. Often enough there are conventions that one has to follow concerning the wrapping of words. Most prominent Names. As an example I will use my name Keith J. Schultz. (Yes, this is not the best example and (Xe)Tex has ways of getting around this) Names should not be wrap or should there not be unnecessary space between the parts. Generally, it is O.K. to wrap/line break after the "J.", but not between Keith and "J." so I need a non breaking space between them, also you do not want different space between "Keith", "J." and "Schultz", yet not the same space as used between other words of the line. If the "J." bothers you use "Johan" instead. The same is true of Mrs. Smith. So the use of a non breaking space with given size is advisable for input. Of course, what TeX et al. should output is debatable and it wreaks havoc with TeX's line breaking algorithm. It is often hard to get the desired results. But, the way TeX works this will always be a problem. Yet, when I enter a non-breaking space that is what I want and more often than not a space of fixed size across the board. regards Keith. Am 15.11.2011 um 12:09 schrieb Philip and Le Khanh: > > > Keith J. Schultz wrote: > >> A non.breaking space is to me a printable character, in so far that >> it is important and must be used to distinguish between word space, et all. > > If, for you, "[a] non.breaking space is a printable character", then > presumably that character must be taken from some font. If you take > a character from a font, it will have a size, and although it can be > combined with kerning rules to adjust its position w.r.t. adjacent > characters, the logic for this is fairly restricted. In particular, > it cannot take into account the amount by which TeX is seeking to > expand or contract spaces on the current line in order to achieve > optimal paragraphs. So in your model of the ideal universe, non-breaking > Unicode spaces would not behave as do conventional > TeX non-breaking spaces (which /do/ expand and contract to assist > in TeX's line-breaking), nor would they conform to their Unicode > definition where their decomposition is defined as : > >SPACE (U+0020) > > I wonder if you would like to discuss these points ? > > Philip Taylor -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
Hi all,
I agree that XeTeX should support all printable characters.
A non.breaking space is to me a printable character, in so far that
it is important and must be used to distinguish between word space, et all.
To go back in history, one of my pet peeves in LaTeX was that I had to
enter the German characters öäüß as \"o, \"a, etc and later the
short cut forms "s, "u, etc. later with inputenc I finally, could just enter
öäüß.But I had trouble, (actually just needed to convert) my files to and from
apple to windows (so that editing was possible on windows).
Yet, I still had trouble with quoting, so I was force to use \quote, et al.
to have a simple method of quoting properly in english, german and french
in one document! I even modified them to suite some requirements I need and
I had one command.
Unicode has thankfully change all this. I can forget about using all those TeX
commands for the characters I need. I just type away.
The only problem is now is the keyboard equivalents and how the editor of
choice
displays them.
Xe(La)TeX doe should not need to worry about how I input a non-breaking
character
it should just respect it.
Some what off topic : What I would like to see is that when in math mode all I
need to
enter is {}[] √∑ in formulas. Sure I could use editor shortcuts, but it would
be nice.
Would be nice if Xe(La)TeX could gain this kind of intellegence.
regards
Keith.
Am 14.11.2011 um 20:50 schrieb Karljurgen Feuerherm:
> I didn't say anything about U+00A0 one way or the other
>
> Keeping in mind that the purpose of this software is to get work done,
> and not to fulfil anyone's philosophical notions of software, my general
> feeling is that:
>
> * Xe(La)TeX should support plain text characters--for *my* present
> purpose, meaning characters which are printable, pure and simple,
> regardless of where in the Unicode space they are; as far as I know,
> this is the case now (and my case in point was more or less just aimed
> at this issue);
>
> * it should support whatever other characters are necessary to complex
> rendering, if it doesn't already;
>
> * optionally it can/could support whatever else, as the in-the-flesh
> maintainers of the package have time and leisure to implement.
>
> I said 'feel', because it seems to me all very well for the rest of us
> to debate philosophy back and forth, but unless we're doing the actual
> work
>
> As someone has already pointed out, lots of what is in Unicode is there
> because it is UNI-code. It may very well have outlived its usefulness,
> at least in the context of Xe(La)TeX doing the work one would like it to
> do. Just because something is in Unicode doesn't mean one has to want to
> use it. In fact, the more unnecessary things one implements, the better
> the chance of instability.
>
> There are no doubt multiple ways to achieve this pragmatically stated
> goal. I don't feel any vested interest in dictating to anyone the
> preference for how to go about it.
>
> K
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
Hi Tobias, Am 14.11.2011 um 18:42 schrieb Tobias Schoel: > > > Am 14.11.2011 18:30, schrieb msk...@ansuz.sooke.bc.ca: [snip, snip] > Now we come to the trouble of Unicode specifying a line-breaking algorithm ( > http://www.unicode.org/reports/tr14/tr14-26.html ), which probably isn't > exactly TeX's. I'm not into these algorithms, so I can't compare. But I would > ask some Master of this Art to speak up about this conflict. I went and briefly look at the annex. In the beginning it states that the annexes are not necessarily a requirement unless mentioned in the standard! I did not check the standard, but as you read on the description of the LBA is not mandatory at all. Furthermore, it more or less describes which characters are directly involved with line breaking (top of table 1). The rest is just a suggest how one Might go about achieving line breaking. This is not a standard at all. Since TeX has its own line breaking algorithms we need not be interrested with the content of this annex as far as Unicode is concerned. What you should be aware of is that the LBA is intended as an aide for a preprocessor to a more elaborate line breaking algorithm. It has been approved for printing, but no where does it state that it must be followed nor that it is complete. In other words it is merely a suggestion. There is no conflict per se. Just another way of dealing with line breaking. There is no real standard for line breaking. It is more or less a matter of taste, style and aesthetics. (Yes, there are many conventions that should be observed, and many are grammatical in nature). regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Hi Zdenek, I am suggesting that one be forced to use any particular editor. But, if we want a unified/consistent editor across all platforms, I would consider TeXWorks as a viable candidate as it is already cross platform. It should be easy enough to add a feature that could make the different forms of white space visible. I do not use TeXworks so I can not say if it works via telnet or ssh. Personally, I think when working with unicode you should use a graphics capable terminal. But, that is just my position. regards Keith. Am 14.11.2011 um 15:16 schrieb Zdenek Wagner: > 2011/11/14 Keith J. Schultz : >> Well, Zdenek, >> >> I guess that is where TeXWorks comes to mind. It could give a unified >> GUI for TeX with unicode. >> > Does it mean I will be forced to use TeXWorks and nothing else? And > will it work over telnet or ssh without graphics? I have other unicode > capable editors if proper fonts are installed but none of them > displays nonbreakable space in a way clearly distinguishable from > normal space. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Hi Herbert, You are absolutely right in your assessment. True plain text files are/where traditionally 7-bits. Though, I have to tell you that nowadays even 8-bit files are considered plain text. The verdict is still out in how far unicode text files are plain text files, as unicode is well unicode and its encoding goes a little further than what be considered as "plain text". Yet, if you considered unicode just as a encoding of text, then unicode is plain text. On the other side in computer science there is, as you said only bits and bytes. It is how we interpret them that makes it text, or plain text, or binary code. regards Keith. Am 14.11.2011 um 14:48 schrieb Herbert Schulz: > > Howdy, > > Gosh, I hate to get into the middle of this but here's my interpretation of > what a plain text file is and why. > > All files are, in fact, just a series of bytes (or even bits) and how these > bytes are to be interpreted determine if the file is a plain text file or > not. Traditional TeX used the 7-bit ASCII set of bytes. Most extensions of > that set have those same byte values representing the same characters so > 7-bit ASCII is usually a sub-set of those extensions (also known as > encodings). A plain text file uses only the common 7-bit ASCII byte set and > virtually any application that can read that file interprets the meanings of > the bytes correctly. The moment you use an extension of that 7-bit ASCII set > an additional piece of information must be given; which encoding is being > used. (There are some heuristics for determining this on the fly but none are > 100% accurate.) Because that extra information must be given before an > application can display the meaning of the file (i.e., replace the bytes by > the characters) I don't consider those files as being plain text. Maybe text > because the int! er! > pretation of the bytes is characters of some sort but not plain text. > > Notice that how those characters are interpreted by other applications has > nothing to do with whether the file is plain text or other text. A Text > Editor interprets the bytes simply as characters and displays them in some > way while pdflatex interprets bytes strings as combinations of commands and > text; same file, different interpretations. > > This is as far as I'm going in this since I really want to stay out of the > argument. It's just my 0.0001 cents. > > Good Luck, > > Herb Schulz > (herbs at wideopenwest dot com) > > > > > > > -- > 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] in XeTeX
Hi Humpty Dumpty,
Go read the standards and cry without kissing the girls.
Evidently, you are trained in computer science or you would
know what a real plain text file is.
Also, in computer science we do not use the definitions of lay persons nor
common language use.
I assume you know all about academia and the use of language.
Or that the language of law for example is quite different that "normal"
langauge.
When you are willing to come back to a serious discussion we talk.
But, troll if you wish.
regards
Keith.
Am 14.11.2011 um 12:08 schrieb Philip TAYLOR:
> Humpty Dumpty might have approved ("When I used a word,"
> Humpty Dumpty said in rather a scornful tone, "it means
> just what I choose it to mean -- neither more nor less.")
>
> but I am afraid I cannot. The definition is /your/ definition,
> not the definition of the general community. Plain text is
> plain text, as I wrote long ago in this thread -- it contains
> letters, digits, punctuation, special symbols, white space
> and ends of line. By definition (the generally accepted
> definition, that is, not a personal idiosyncratic one), none
> of those letters, digits, punctuation, special symbols,
> white space or ends of line have any special significance,
> and certainly no greater significance than they would
> have were they to appear (say) printed on a sheet of paper.
>
> As soon as you define any one of those things to have special
> significance (as do Runoff, GML, SGML, HTML, XML, TeX, ...),
> the document ceases to be plain text and becomes structured
> text.
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Hi Chris, I agree with you that one should be able to see the differences in an editor, but this feature should be feature to turn off and on. The question is what is an ordinary editor. Also, most prefer to use their pet editors. regards Keith. > I get worried when reserved characters are not visually differentiated > in an ordinary text editor from non-reserved ones. > > I think it's far better if one can have packages which enable or > disable these specific characters for those who want them. However, > don't make me open a hex editor to see why a space is breaking or not. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Well, Zdenek, I guess that is where TeXWorks comes to mind. It could give a unified GUI for TeX with unicode. regards Keith. Am 14.11.2011 um 11:38 schrieb Zdenek Wagner: > You live in a perfect world where you can do everything with a single > editor using nice GUI. The world is not yet that perfect. How do I use > color when aditing a file using ssh and colorless terminal? What is > the Unicode standard color of NBSP? I do not edit files just on my > computer, I have to support customers, I have to cooperate with > colleagues. they use different platforms, different editors. If they > all use TeX, I know that ~ denotes nonbreakable space. What is a > world-wide platform independent and color independent visible > representation of a nonbreakable space that is clearly distinct from a > normal space? -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Well, XeTeX users are already restricted in their choice of editors. The must/should support minimalistically unicode. Of course you can enter the characters/glyphs in a cryptic manner. Have fun reading a text with true unicode! Also, remember when you had to use ALT-XXX for entering characters your keyboard did not have in WORD! I know/knew quite a few of windows users that envy me entering mixed language texts on my Apples! regards Keith. Am 14.11.2011 um 11:27 schrieb Chris Travers: > On Mon, Nov 14, 2011 at 2:24 AM, Petr Tomasek wrote: > >> Using different color. >> > Do we really want to tie XeTeX users to a small number of editors? > > Chris Travers > > > -- > 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] in XeTeX
Hi there, Am 14.11.2011 um 11:20 schrieb Chris Travers: > My $0.02 > > In general, I think we are going to get the most mileage by sticking > with the TeX way of doing things by default. The nice thing is that ~ > can be turned into a non-active character, and one can set other > things if they want. For the record, I think that having non-breaking > spaces in a plain text document is a bad idea. I mean, you have > essentially invisible control characters. What could possibly go > wrong? Hey, it could be worse. I've seen programs that use "magic > comments." > > As long as one can make other characters active instead, I see no > reason to worry about this. > > But the point is that when I am debugging a TeX file I want: > 1) To be able to use an editor of my choice and > 2) To be able to see clearly what is going on. > > The fact that Python, for example treats whitespace as semantically > meaningful and hence treats tabs and spaces as semantically different > is a big strike against that language, for example, from a semantic > clarity perspective despite the fact that this was ironically a > decision that was made in order to support semantic clarity. Well, a Tab an several spaces are semantically different! How much space is a tab character give you! > > TeX files are never simple plain text files, and I don't think we > should pretend that they are. Well, it depends if you mean "plain text" file or "plain text file". What does the definition/standard of TeX says it takes as input. Things where a lot easier when TeX came to life and the definition of a plain text file, also! regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Hi Zdenek, all, I was to lazy to list all those encodings. I will be more precise know for those not reading carefully. There is a difference between what is considered plain text in the computer world and what its content is. Basically, plain text is just that text no matter what its content is. That is in the computer world you can have PLAIN TEXT FILES and have content that is TeX, et all, HTML, XML, SGML and for most programming languages. That is the source for these languages are in a more or less human readable format --- TEXT. Whether, the due to the syntax of the language represented a character can be used directly or an "Escape" character to represent them is irrelevant. Naturally, you have to know the syntax to understand the text. Still it is plain text according to the standards that define the content of the files. As I said I guess Unicode should be considered as plain text. Yet, unicode is special in the same way as ASCII and Extended ASCII, 7-bit ASCII and 8-bit ASCII depending on the fonts you used you got different results when output on the screen or printer. The problem there are not any fonts that implement the FULL unicode set. What is what is needed. On the other side, until we have OSes that truly fully support unicode, unicode can be truly considered to be plain text. As far a TeX is concerned it was not designed to handle unicode or even 8-bit. It has been though fragmented to handle them. It has come at a cost. It would be time to redesign it. refractor if you will. regards Keith. Am 14.11.2011 um 11:07 schrieb Zdenek Wagner: > It's not the encoding that determines whether it is a plain text. > Texts in ISO 8859-1, CP852, UTF-8, UTF-16, BIG-5 can be plain texts. > LTR/RTL is no problem in modern editors, I can easily combine > Czech/English/Hindi/Urdu (uses arabic script) in a single document, > the languages/scripts may even be mixed within a paragraph. What > determines whether it is or is not a plain text is the presence or > absence of control characters or commands no matter whether the file > can be viewed and/or edited in a plain text editor such as vim or > notepad. If I type < I wish it to mean "less that" but in XML it marks > the element tag, If I need such a character in XML or SGML, I have to > write < no matter what editor I use. If it were plain text, < > would mean ampersand followed by the letters lt and a semicolon. If I > type & in a plain text, it means "and". If I type it in a TeX file, it > is a special character for \halign (unless \catcode is changed), in > XML and SGML it means that all following characters up to the first > semicolon is an entity name. If I have to insert an ampersand, I have > to write \& in TeX or & in XML and SGML. There are different > methods how to enter A, eg ^^41 in TeX or A in XML and SGML. As > Phil wrote, there is a clearly defined MIME type for a plain text. > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Hi Peter, Simple answer No do not use the emacs editor, hate it! I have not look at emacs in a very long time, but I assume that it does not understand unicode, along with other text encodings. But, you can edit TeX, HTML, and XML with it! Please see my responses to Phillip and Zdenek for more insight. regards Keith. Am 14.11.2011 um 11:10 schrieb Peter Dyballa: > > Am 14.11.2011 um 09:21 schrieb Keith J. Schultz: > >> So, Unicode needs an editor to be displayed correctly. > > Use GNU Emacs! > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Hi Phillip, Am 14.11.2011 um 09:36 schrieb Philip TAYLOR: > > > Keith J. Schultz wrote: > >> So, Unicode needs an editor to be displayed correctly. > > Why ? Not meant to sound aggressive, but seems a very > odd assertion, IMHO. Editors are for changing things; > why would you need a program intended to change things > just to display Unicode ? Yes, there are other programs for displaying texts. I was thinking about a unix command such as cat, less, more, etc. Depending on a few things they will not necessarily display a Unicode text file correctly ! > >> Now, for the youngsters XML, TeX, HTML are per definition plain text files. > > No, they are text files, not /plain/ text files. Look > at some mime types : > > text/plain (for plain text) > text/html (for HTML) C'mon Phillip! I wrote "per defintion" ! That is the file is plain text. the plain text "text/html" is for the browser so that it knows a file contains html-tags/commands and interpret accordingly during display! Just like in XML the data tag can contain binary data, yet it is entered in HEX! Though, I believe in the newer standards binary can be entered directly! Been a long time since I look at the actual standard. Also, for most programming languages the source is a plain text file, even though its content is in a programming language. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] in XeTeX
Hi Everybody,
Slow down a bit. Sorry if I sound high headed here!
There seems to be a misunderstanding what exactly a
PLAIN TEXT FILE is.
Computing has evolved since I started using computers.
When I started out a plain text file was a file just holding
7-bit ASCII or EBCDIC, or the like without control characters, except
EOF, CR,or LF! No, FF or TAB (sometimes allowed) and the others.
Eventually, files with 8-bit coding became plain text.
I guess we can consider in this modern day and age Unicode plain text.
Though, to be fair Unicode encodes glyphs, and can signal RTL usage.
So, Unicode needs an editor to be displayed correctly. But, the question is
philosophical.
Now, for the youngsters XML, TeX, HTML are per definition plain text files.
WHAT, they do contain are commands in plain text that describe how the
information inside is to be display. Yet, a human can still read the text
inside and
understand what is going on.
Again, with unicode coming into the picture things do get somewhat more
complicated
as the glyphs have to be displayed properly, so that a human can properly read
it.
This is do to the vastness of Unicode.
Now, to the problem of copying and pasting. What does happen!
I will take the HTML case! When you copy text from a browser with
&nnsp. Do you get '&nnsb', a simple blank, or a true no blocking space!
Most likely you will get a simple blank, it depends.
If you do get a true non-blocking space what happens if you paste it into
a different editor? Chances ore good you get a funny character displayed.
So, it boils down to the tools you use.
That said, we come to how do we display all these great glyphs. Most are easy
enough,
white space is very hard for humans to read, they are just that white.
Some the different types of white space should be displayed differently. The
same could be
said of glyphs that are composed instead of being just one represented by one
glyph.
The problem is how to do it so that it does not look ugly or very confusing!
In other words, we have to live with some compromises! That is easy discern
ability or ease of readability.
regards
Keith.
Am 13.11.2011 um 19:46 schrieb Tobias Schoel:
>
>
> Am 13.11.2011 20:25, schrieb Zdenek Wagner:
>> (La)TeX source file is not a plain text. Every LaTeX document nowadays
>> starts with \documentclass but such text is not present in the output.
>
> Of course, the preamble isn't plain text, but mostly macros. I thought of the
> body of the document. I think, it's common practice for larger documents to
> have a main latex file, which reads \documentclass …
> \begin{document}\input{first_chapter}\input{second_chapter}…\end{document}
> In these cases, the input documents are more or less plain text (depending on
> the subject).
>
>> Even XML is not plain text, you can use entities as ,' and
>> many more. Of course, if (La)TeX is used for automatic processing of
>> data extracted from a database that can contain a wide variety of
>> Unicode character, it is a valid question how to handle such input.
> Or if the content is copy-pasted, from let's say HTML. But who would do that …
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Ftuture state of XeTeX in TeXLive
Hi Tobias,
Polyglossia works fine for german! I believed you missed a error message.
You have to change one line, you need:
\defaultfontfeatures{Ligatures=TeX}
regards
Keith.
Am 28.10.2011 um 16:53 schrieb Tobias Schoel:
> As a simple user (very simple: none of my work gets published, I just use TeX
> for myself): What do I have to think about, when moving from XeLaTeX to
> LuaLaTeX?
>
> I took a random document I created last week and tried to compile it with
> lualatex instead of xelatex. It threw an error because of polyglossia. OK, I
> commented out polyglossia. It compiled without error but hyphenation was
> broken (the text was German). I added \usepackage[ngerman]{babel} [would be
> great error in xetex as I read often on this list] and the document compiled
> without errors and with good hyphenation.
>
> So was it luck or should this be standard?
>
> bye
>
> Toscho
>
> Am 28.10.2011 16:33, schrieb Vafa Khalighi:
>> As an example, the attached PDF is just a portion of a maths textbook
>> with the title "Theory of Ordinary Differential Equation and Dynamic
>> Systems" which has been typeset using XePersian andit is published
>> just today in Iran.
>>
>> http://www.mehrnews.com/fa/newsdetail.aspx?NewsID=1440752
>>
>>
>>
>>
>>
>> --
>> 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] Performance of ucharclasses
Hi Phillip, We are not talking about native English speakers here, but legal language. How a court will decide, depends on many factors. Either way, we can only speculate what will happen and we do not know the true intension of the author. regards Keith. Am 26.10.2011 um 10:49 schrieb Philip TAYLOR (Webmaster, Ret'd): > > > Keith J. Schultz wrote: > >> 2) Intellectual Property Rights >> This controls modification of code and use thereof. >>In our case, the author discourages this, and basically >>denies us the right to do it. > > He does /not/ deny you the right to do so; he discourages > you, which any competent native speaker of English would > recognise as being completely different. > > Philip Taylor > > > -- > 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] Performance of ucharclasses
Hi Tobias, All, This is getting a little OT, so please forgive. For clarity, we have several issues at stake here. 1) Copyright This will control distribution and the use thereof. In our case we can use the package for creating texts. We may distribute the unmodified code with our code! But, the third party does not have the right to the package as they wish without obtaining it themselves. For the legally minded this last point has plenty of dispute in it, but depends on the exact license. Propriety Fonts are a good example. 2) Intelectual Property Rights This controls modification of code and use thereof. In our case, the author discourages this, and basically denies us the right to do it. Just putting a wrapper around it or just changing a few names or lines, making it more eficient will generally not constitute a new idea or product. This is a very hairy topic. Look, at the patent wars in the mobile phone market for examples! Mike should chime in here and clarify. He should also change his license to be more specific. regards Keith. Am 25.10.2011 um 17:32 schrieb Tobias Schoel: > > > Am 25.10.2011 10:30, schrieb Keith J. Schultz: >> O.K. I will jump in here. >> >> Intellectual property rights are often a great big gray zone. >> Maybe, it is time the author of the package speaks up himself >> what is meant. > That would help. > >> >> Also, it does seem clear if the code being used or parts thereof are from a >> different party, who may or may not have rights which they will enforce. >> >> Furthermore, the author at least signals, s/he wants to keep control of the >> code. >> The use of "discouraged" indicates that the author or a third party may or >> may not >> go to court over the modified version. It is very clear that the author does >> not want >> modified versions being distributed. I admit that stronger legal terms >> should have been >> used. > It's clear that he wants to keep control of the code of the package called > ucharclasses . What is not clear at all, is, whether one might borrow freely > from this package when writing a different package. This issue is not covered > exactly as this. It is allowed to use the package freely. A definition of > "use" is missing. One might argue, that copying the text, changing it and > calling it the foobar package, is use. > >> >> As the author has used this fuzzy legal terminology, it very hard to say how >> a judge might >> rule. It is like parking a car just because the car is not parked inside of >> a no parking zone >> you could still get a fine. > Exactly: copyright laws still apply. So a restriction in a software license > is usually nonsense: Everything that is forbidden by law need not be > forbidden by license. Everything that is not forbidden by law can't be > forbidden by license. (This might depend on the judicion, so it's probably > wrong in the USA.) > >> >> It is sane not to include this package in TeXLive as to avoid the >> complications above, as >> you never know want a contributor may do with the code and unknowingly cause >> problems >> and why should TeXLive put effort into a package that is not freely >> available, to ensure that they >> right side of the law. >> >> regards >> Keith. >> [snip, snip, original post] -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Performance of ucharclasses
O.K. I will jump in here. Intellectual property rights are often a great big gray zone. Maybe, it is time the author of the package speaks up himself what is meant. Also, it does seem clear if the code being used or parts thereof are from a different party, who may or may not have rights which they will enforce. Furthermore, the author at least signals, s/he wants to keep control of the code. The use of "discouraged" indicates that the author or a third party may or may not go to court over the modified version. It is very clear that the author does not want modified versions being distributed. I admit that stronger legal terms should have been used. As the author has used this fuzzy legal terminology, it very hard to say how a judge might rule. It is like parking a car just because the car is not parked inside of a no parking zone you could still get a fine. It is sane not to include this package in TeXLive as to avoid the complications above, as you never know want a contributor may do with the code and unknowingly cause problems and why should TeXLive put effort into a package that is not freely available, to ensure that they right side of the law. regards Keith. Am 23.10.2011 um 18:59 schrieb Philip TAYLOR (Webmaster, Ret'd): > > > msk...@ansuz.sooke.bc.ca wrote: >> On Sun, 23 Oct 2011, Philip TAYLOR (Webmaster, Ret'd) wrote: >>> clearly they are -- but in terms of actual requirements. Since >>> you are only "discouraged from" and not "prohibited from" >>> making changes, I believe that a court of law would find that >>> there is no actual inconsistency in practice. >> >> Do note that the ucharclasses package isn't covered by the LPPL at all. >> The author is free to put whatever license he wants on it, and whether >> the license he chose is consistent with the LPPL isn't particularly >> relevant. We might as well as whether it's consistent with the GNU GPL >> or the Argentinian Constitution. > > The issue that Vafa raised was as follows : > >> No, the license of the package in not LPPL. > > In fact, it is non-free and that is why it > > is not included in TeXLive. The README in "License" section says: > >>> You >>> may freely use this package, but you are discouraged from >>> modifying this package and then redistributing it. Instead, >>> please contact me (ideally on the XeTeX mailing list) and >>> we can discuss the changes you wish to make. If they >>> benefit everyone, they will be worked in as a new version. > > and the point that I was making is that "discouraged from" > is not the same as "are not allowed to" and therefore should > not be taken as an reason to exclude the package from TeX Live. > Whether the package licence conflicts with the LPPL, or with the > GNU PL, or with the Constitution of Argentina, is not really > the point at issue. > > Philip Taylor > > > > > > -- > 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] polyglossia and french
Hi All,
For what it is worth I see two roads to follow.
1) create a glossary for swiss-french
2) modify the french glossary to accommodate swiss-spacing.
Following 1 has the advantage that it keeps the french glossary clean. Yet, to
follow this road
causes a problem with maintaining another glossary for a french variant. The
question then is
is the difference between french and swiss-french is that great to warrant such
a move.
Following 2 can increases maintainability, all that would be needed would be a
command like
\swissspacing@punctionuation model after:
\def\nofrench@punctuation{%
\lccode"2019=\z@
\XeTeXcharclass `\! \z@
\XeTeXcharclass `\? \z@
\XeTeXcharclass `\‼ \z@
\XeTeXcharclass `\⁇ \z@
\XeTeXcharclass `\⁈ \z@
\XeTeXcharclass `\⁉ \z@
\XeTeXcharclass `\; \z@
\XeTeXcharclass `\: \z@
\XeTeXcharclass `\« \z@
\XeTeXcharclass `\» \z@
\XeTeXcharclass `\‹ \z@
\XeTeXcharclass `\› \z@
\XeTeXinterchartokenstate=0
}
This approach is modular and would allow a quick way of switching between the
two "languages"
If there are more sublimities one could use a command/switch like \swissfrench.
I believe route 2 is the saneness one to follow.
regards
Keith.
Am 25.09.2011 um 10:07 schrieb rhin...@postmail.ch:
> On Sun, Sep 25, 2011 at 09:11:55AM +0200, Zdenek Wagner wrote:
>> 2011/9/25 Mojca Miklavec :
>>> On Sat, Sep 24, 2011 at 22:55, Alan Munn wrote:
On Sep 24, 2011, at 3:34 PM, rhin...@postmail.ch wrote:
> Hi All,
>When typesetting documents in french with polyglossia,
> a space is added before double punctuation signs (like !:?...).
>
> This is normal in french typography used in France. However,
> here in Switzerland, it is more usual to not use this
> extra space.
>>> /.../
There's a command \nofrench@punctuation which turns off all the French
related punctuation.
>>> /.../
So to selectively turn off the special spacing for particular characters,
redefine this command by commenting out the lines that correspond to
spacing that you wish to keep, and then issue the command to turn of the
uncommented ones.
>>>
>>> I don't know anything about French in Switzerland, but if such a usage
>>> is common, it makes more sense to add an option to Polyglossia to
>>> switch French spacing off with a package option/language-specific
>>> setting instead of resorting to low level commands.
>>>
>> I have received a private mail from François Charette saying that he
>> no longer has time to maintain polyglossia and he offered the package
>> to others to become maintainers. I myself will not have any time tilll
>> the end of this year and moreover do not know git and have no time to
>> learn it. If someone is able to clone it, migrate it to subversion (or
>> cvs) and become a new maintainer, i will actively join the team of
>> developers in January 2012.
>>
> Hi All,
> Thanks for replying me with these ideas. I could perhaps
> do a part of the work since I will have a certain amount of time
> until the end of year.
>
> As far as I know, GIT is not very different from CVS/Subversion
> (the joke about Git is that it is the answer to the question:"who is the boss
> ?").
> Where the CVS/Subversion repository should be located ? For me, the choice
> of
> a source control system is not a big problem: I can work with all the three.
>
> I think effectively, that an option to the package could be a nice solution,
> since it is possible that other differences occur. For instance the wording
> could be sometimes different from the french spoken in France
> (like the difference between American an British english).
>
> What does imply to add an option "romand" (the french speaking part of
> of Switzerland is often called "Romandie") to polyglossia. Should I clone
> the Git repository, do the modifications and hope they will be integrated
> in the main stream ?
>
>
> best regards,
>
> Alain
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Compatibility issues with ednotes and pstricks or TikZ
Hi Mathew, I think you are being a bit unfair towards Vafa! LaTeX, et al are highly complex. The advent of unicode has not made things easier. The problem is not that bidi or the other package is "faulty", but in the way it is done, so that when then two are used together the result is not what is expected by the average user. Adding support often means changing the way certain TeX commands work so that the expected result comes out. Also, many packages do not give the expected result when you switch from LTR to RTL. The fault is not necessarily that of the author of a package, because the never thought of using RTL. Now, if some uses such a package and is using bidi, too, the result is not what is expected. So that person complains to Vafa, because the other package seems to work properly! So, as you can see that it is not Vafa, fault. Is it Vafa responsibility to make sure all other packages support all features that bidi needs! NO. That should be the responsibility of the author of the other package. So what Vafa, does is try to figure out why and how the other package does something and change that "flaw"(I should say short coming). If you have ever written a non-trivial package or environment, you would understand. Everythings seems to work dandy. Then, you add another package to your text and things break!!! regards Keith. Am 24.09.2011 um 00:49 schrieb msk...@ansuz.sooke.bc.ca: > On Fri, 23 Sep 2011, VAFA KHALIGHI wrote: >> When I started as the maintainer of bidi, I contacted some of the >> package/class authors unfortunately no one even bothered to reply back (at >> least saying, no I do not have time or I do not know how to do it) and >> indeed that is why bidi itself, support so many packages. > > Knowing that your attitude is that compatibility is everybody else's > job and not yours, I sure wouldn't have been quick to reply to you if I > were one of those package maintainers. > > Perhaps it's not really what you meant to say, but when I read this > comment of yours: > >> it is not the duty of bidi package to add support for other packages but >> other packages themselves have to add bidi support. bidi should only support > > it created a very negative impression. I get the idea that some of your > difficulties with other package maintainers may be to some extent of your > own making. > > My own point of view is that compatiblity should involve effort and > accomodation on *both* sides. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Compatibility issues with ednotes and pstricks or TikZ
Hi Vafa, I kind of figured as much. The only, I can do for you is to ask. Can anybody. please help him. I assume many problems is that the packages either do not support unicode of are not designed to work with RTL. I am sure if the packages are fixed other problems should go away. I do not if this is feasible or workable, but at least packages for Lua(La)TeX should require that they support unicode and RTL fully before they are accepted to the repository. regards Keith. Am 23.09.2011 um 10:41 schrieb VAFA KHALIGHI: > > >Vafa, have you tried asking the authors of the packages that you > support(work around their short commings) > to support, bidi or RTL. They are most likely not aware of the > problems, because the designed their package > only of LTR. Maybe you, can gather a group around you that will modify > and update the other packages. > KEEP UP THE SUPERB WORK. > > When I started as the maintainer of bidi, I contacted some of the > package/class authors unfortunately no one even bothered to reply back (at > least saying, no I do not have time or I do not know how to do it) and indeed > that is why bidi itself, support so many packages. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Compatibility issues with ednotes and pstricks or TikZ
Hi Nathan, Vafa, TeX, LaTeX, Xe(La)TeX, Lua(La)Tex, etc come with a very steep learning curve. It was one of the reasons I stopped using LaTeX some 20 years ago. Also, back then the packages were not stable and conflicted with each other so if really needed something you had better do it yourself. THAT was THEN. Today, a lot has changed and become very stable and usable. Evenmore so, with the support of unicode. The problem is that there is NO MODERN Reference for LaTeX, Xe(La)TeX or Lua(La)TeX that is usable for finding packages for the simple user of TeX et.al. Even the all so famous LaTeX Companion is helplessly outdated. Believe, me! I had bought the latest available version of the Book. If I had not started delving into TeXLive via the show info panel of the TeXLive utility, I would have given up on TeX, again. You have to avoid older packages as much as possible. Look for newer packages. Look carefully, at Koma Scripts and Memoir, you can probably get more functionality by adapting from them. For Graphics, avoid ps-tricks, use some newer. TikZ and pgf are quite able and simple enough to learn and more packages are coming out that use them. Vafa, have you tried asking the authors of the packages that you support(work around their short commings) to support, bidi or RTL. They are most likely not aware of the problems, because the designed their package only of LTR. Maybe you, can gather a group around you that will modify and update the other packages. KEEP UP THE SUPERB WORK. Sorry, I this is somewhat OT, to others. regards Keith. Am 23.09.2011 um 07:54 schrieb Nathan Sidoli: > Yes, of course you are right. However, many of the older LaTeX packages are > not being developed very actively any more (or not at all in some cases) so > it makes it difficult to decide what to use when one need the functionality > of some of the older packages but also wants to work with unicode, etc. > > Anyway, you have certainly done a great deal to make bidi very functional and > I am very grateful for that. > > > On 11/09/23 12:09, VAFA KHALIGHI wrote: >> >> >> >> For how long have bidi and ednotes been incompatible? François Charette , >> who maintains arabxetex and works on polyglossia, wrote an example file >> showing how to use arabxetex + bidi with ednotes to produce critical >> editions, so I assumed there would be some effort to keep the packages >> compatible. >> >> >> >> Well, certainly bidi can not support every single package on CTAN, one would >> need unlimited resources to be able to do that. bidi itself is now too big, >> it supports around 100 packages. Unfortunately the concept is misunderstood, >> it is not the duty of bidi package to add support for other packages but >> other packages themselves have to add bidi support. bidi should only support >> standard LaTeX and considering this, I have done heaps more than I ought to >> do. So it makes sense if you contact the author of ednotes package and ask >> him for bidi support in his package. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
O.K. for the slow! Here a little more of the quote: > If you want to create new binaries which also run on Tiger you need the > MacOSX10.4u.sdk *and* GCC 4.0.1. Maybe, not an expert. We would not be compiling for 10.4 anyway. Not even MacTeX 2011 supports 10.4! Are you sure you know what you are talking- er- writing about!! The discussion is about getting xetex to use Core Text so that it can be 64-bit, more specifically Lion and up! Second, to my knowledge Tiger is basically a 32-bit system (Yes, Yes it could run 64-bit code) and the TeXLive code base is basically frozen for Tiger. (Yes, Yes it is possible to do upgrades to packages). Third, I did not want to get into the intrinsics of compiling on the Mac, just if over at MacTeX they use a particular compiler for their Package, more specifically, TexLive 2011. Fourth, (of course Peter can not know this) I have had Apples since the FIRST Apple IIe came out and developed on them. regards Keith. Am 02.09.2011 um 15:03 schrieb Martin Schröder: > 2011/9/1 Keith J. Schultz : >>Are you sure you know what you are talking- er- writing about!! > > Yes. > Please stop waisting all those "!". > > Best > Martin > -- > 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] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Am 01.09.2011 um 22:01 schrieb Peter Dyballa: > > Am 01.09.2011 um 21:12 schrieb Keith J. Schultz: > >> Are you sure you know what you are talking- er- writing about!! > > Yes. > > The problem is with libgcc (or libstdc++ or libobjc). You don't need to > include it in the static binary, because the target OS has it. Tiger has only > the GCC 4.0.1 libraries, so, when you're clever, you don't compile with GCC > 4.2.1 or LLVM GCC 4.2. > So If I follow you right I should build a 64-bit xetex for Tiger! ;-))) regards Keith -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Am 01.09.2011 um 20:42 schrieb Peter Dyballa: > > Am 01.09.2011 um 20:13 schrieb Keith J. Schultz: > >> Furthermore I do not know which compilers are used over at MacTeX as this >> does matter >> in ways which are far to complicates to discuss here. > > It's not only a question of compilers – you also need SDKs! Not to sure about that there are others ways. But, You are the expert! > > If you want to create new binaries which also run on Tiger you need the > MacOSX10.4u.sdk *and* GCC 4.0.1. Maybe, not an expert. We would not be compiling for 10.4 anyway. Not even MacTeX 2011 supports 10.4! Are you sure you know what you are talking- er- writing about!! > If you want to create new binaries which also run on Leopard you need the > MacOSX10.5.sdk and you can use GCC 4.2.1. > If you want to create new binaries which also run on Snow Leopard you need > the MacOSX10.6.sdk and you can use GCC 4.2.1 or LLVM GCC 4.2. > > The Tiger and Leopard SDKs are provided by Xcode 3.1...3.2.6 (the latter also > provides Snow Leopard), the Xcode 4.x versions provide only Snow Leopard. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Thanx Dicl for your sober response. Basically, that was the intension of my message here. The problem is that I am not a texnician, not do I know much, to say anything, about electronic typography. I was hoping to get pointers, before I just download the the xetex source and work through before I could even start to work on replace ASTUI with Code Text. Furthermore I do not know which compilers are used over at MacTeX as this does matter in ways which are far to complicates to discuss here. regards Keith. Am 31.08.2011 um 17:47 schrieb Richard Koch: > [snip, snip] > Having said all of that, it would be wonderful if someone would take on the > task of converting the Macintosh portions of XeTeX from ATSUI to Core Text, > since it would remove the worry that Apple (at some distant time) would > remove the 32 bit ATSUI Library from the system, and would allow us to compile > all of TeX Live in 64 bits. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Am 31.08.2011 um 20:12 schrieb George N. White III: > On Wed, Aug 31, 2011 at 12:47 PM, Richard Koch wrote: >> Folks, >> >> [snip, snip] >> Having said all of that, it would be wonderful if someone would take on the >> task of converting the Macintosh portions of XeTeX from ATSUI to Core Text, >> since it would remove the worry that Apple (at some distant time) would >> remove the 32 bit ATSUI Library from the system, and would allow us to >> compile >> all of TeX Live in 64 bits. > > It might be better to put energy into other projects (luatex and supporting > libraries). If x86_64 xetex is needed, simply follow macports and > compile for x86_64 using open source libraries. The only reason the Macports version is 64-bit is because they removed the ASTUI support!! They have not replaced it. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Excuse ME! Peter. What is you problem The call to Core text offer the same results as ATSUI!!! So no instability is introduced! Am 31.08.2011 um 15:30 schrieb Peter Dyballa: > > Am 31.08.2011 um 12:02 schrieb Keith J. Schultz: > >> Nothing is considered stable just yet. > > The same would be true when you try to port XeTeX from ATSUI to CoreText. > >> >> In other words, xe(la)tex would be the way to go. For awhile. > > And therefore keep old versions of Mac OS X! Leopard and Snow Leopard are OK > (it depends on the hardware it will run on: Mac OS X must be younger than the > hardware or it won't run on something it does not know). You can either clone > your recent installation onto a smaller external disk, connected through > FireWire, because this enables the Mac to boot from it, or onto an extra > internal disk (when you're using a desk-side computer), or you can try to > create a virtual instance of a Mac OS X version in which XeTeX is supported. I have and still use some very old hardware and software. But, that is a different matter. Woof! Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Hi Peter, Am 30.08.2011 um 23:30 schrieb Peter Dyballa: > > Am 30.08.2011 um 16:43 schrieb Keith J. Schultz: > >> ATSU is deprecated and replaced by Core Text for handling unicode as of >> Leopard. >> >> So, xetex has to be refractured or rewritten to use Core Text on the Mac. > > Why? XeTeX pioneered in the use of Unicode in TeX. Its development has come > to a stop. LuaTeX is being developed. Do we need three Unicode TeXs? (The > third one is pTeX.) Simple! Right out of the LuaTeX manual: Features may come and go. The current version of LuaTEX is not meant for production and users cannot depend on stability, nor on functionality staying the same. Nothing is considered stable just yet. In other words, xe(la)tex would be the way to go. For awhile. Also, I did not want to learn Lua. Oh, Well another programming language to add to the up-tine programming languages I already have in my head. I will give it a whirl. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Hi George, I just did some checking and it seems it is possible to replace the calls to ATSUI with calls to Core Text with identical results. No, I have not test this with xetex, but it seems to work with engines that support ATSUI. Their are also compatibility calls for Core Text for calling Quick draw routines for text, though xetex should not be using them anyway! ATSUI is a Mac only thing and deprecated and more or less dead. But, I would agree that everything could probably done by Graphite, so all that would be needed is a graphite layer for the different OSes. regards Keith. Am 30.08.2011 um 18:47 schrieb George N. White III: > On Tue, Aug 30, 2011 at 4:53 AM, Keith J. Schultz > wrote: > >> Hi George, >> >>The Macports version of xetex is built 64-bit, but it does not have >> ATSU features. >>so it is not "fully" functional. >> >>The question is if there is an actual need to still support ATSU at >> all? >>If we do the question is how hard would be to rewrite the needed >> libraries. > > For some (my!) purposes, documents formatted across macosx, linux, and > windows need to come out the same (multiple authors working in different > locations with different IT "standards") but the docs are manuals and > scientific > reports with relatively few non-ASCII elements (mostly proper names) outside > the math. I can imagine that some documents really do need Apple > font technology, so at present those who need ATSU have to get by without > the 64-bit binaries. > > Only those who really need ATSU can explain what they need -- perhaps it is > possible improve open source libraries to provide what is needed. Many more > people are interested in improving the open source libraries than are > interested > in xetex on macosx. > >>If this is the wrong place to discuss this, please point me in the >> right direction. > > One of the most useful sources on information about problems in font > libraries may > be bug reports, both those filed against xetex on other platforms and > against the open > source libraries. A few years ago there were some quite insightful > discussions of > problems with the open source libraries (including comparisons with MS and > Apple) -- don't know if those have been updated. This an area where > things are > developing rapidly, so I'm sure there have been significant changes. > There are higher > level libraries that hide platform differences, while taking advantage > of native support > on each platform. This could be a better way forward than simply > updating the Apple > font library calls, but one would need to check that the higher level > libraries are > available everywhere xetex is needed. > >> regards >>Keith. >> >> >> Am 30.08.2011 um 02:57 schrieb George N. White III: >> >>> On Mon, Aug 29, 2011 at 2:32 PM, Keith J. Schultz >>> wrote: >>>> Hi Herbert, >>>> >>>> You are right their is font library that is deprecated and only allows >>>> xe(l)tex to be built 32-bit! >>>> This will have to change as the Mac world has going 64-bit. Yes, you can >>>> run 32-bit programs >>>> under Lion, but it also comes at a performance price. >>>> >>>> Anyone know exactly which library and how hard it would be to refractor or >>>> rewrite? >>>> >>> >>> See the thread called "ATSUGetAttribute not found" on the tlbuild list >>> for a discussion. >>> >>> Macports worked around the problem by building xetex using open source >>> libraries: >>> >>> $ /opt/local/bin/xetex --version >>> XeTeX 3.1415926-2.3-0.9997.5 (TeX Live 2011/MacPorts 2011_1) >>> kpathsea version 6.0.1 >>> Copyright 2011 SIL International and Jonathan Kew. >>> There is NO warranty. Redistribution of this software is >>> covered by the terms of both the XeTeX copyright and >>> the Lesser GNU General Public License. >>> For more information about these matters, see the file >>> named COPYING and the XeTeX source. >>> Primary author of XeTeX: Jonathan Kew. >>> Compiled with ICU version 4.6 [with modifications for XeTeX] >>> Compiled with zlib version 1.2.5; using 1.2.5 >>> Compiled with FreeType2 version 2.4.6; using 2.4.6 >>> Compiled with fontconfig version 2.8.0; using 2.8.0 >>> Compiled with libpng version 1.4.8; using 1.4.8 >>> Compiled with poppler version 0.16.6 >>> >>> $ file /opt/local/bin/xetex >>> /opt/local/bin/xetex: Mach-O 64-bit executable x86_64 >>> >> >> >> >> >> -- >> Subscriptions, Archive, and List information, etc.: >> http://tug.org/mailman/listinfo/xetex >> > > > > -- > George N. White III > Head of St. Margarets Bay, Nova Scotia > > > > -- > 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] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
ATSU is deprecated and replaced by Core Text for handling unicode as of Leopard. So, xetex has to be refractured or rewritten to use Core Text on the Mac. My question is how much of the code of xetex depend on ATSUI, so how hard would it be. I am not a font tech geek or such. Maybe Mr. Kew can comment. regards Keith Am 30.08.2011 um 11:15 schrieb Peter Dyballa: > > Am 30.08.2011 um 09:53 schrieb Keith J. Schultz: > >> The question is if there is an actual need to still support ATSU at all? > > This question could probably be answered on some fonts or font technologies > related list. Maybe Apple folks could contribute by answering whether Apple > is going to support their own font development. > >> If we do the question is how hard would be to rewrite the needed >> libraries. >> > > Some Mac developers list would be appropriate for this. > > -- > Greetings > > Pete > > Real Time, adj.: > Here and now, as opposed to fake time, which only occurs there and then. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] 64.bit XeTex was::Re: Trying to build microtype-aware xetex
Hi George, The Macports version of xetex is built 64-bit, but it does not have ATSU features. so it is not "fully" functional. The question is if there is an actual need to still support ATSU at all? If we do the question is how hard would be to rewrite the needed libraries. If this is the wrong place to discuss this, please point me in the right direction. regards Keith. Am 30.08.2011 um 02:57 schrieb George N. White III: > On Mon, Aug 29, 2011 at 2:32 PM, Keith J. Schultz > wrote: >> Hi Herbert, >> >> You are right their is font library that is deprecated and only allows >> xe(l)tex to be built 32-bit! >> This will have to change as the Mac world has going 64-bit. Yes, you can run >> 32-bit programs >> under Lion, but it also comes at a performance price. >> >> Anyone know exactly which library and how hard it would be to refractor or >> rewrite? >> > > See the thread called "ATSUGetAttribute not found" on the tlbuild list > for a discussion. > > Macports worked around the problem by building xetex using open source > libraries: > > $ /opt/local/bin/xetex --version > XeTeX 3.1415926-2.3-0.9997.5 (TeX Live 2011/MacPorts 2011_1) > kpathsea version 6.0.1 > Copyright 2011 SIL International and Jonathan Kew. > There is NO warranty. Redistribution of this software is > covered by the terms of both the XeTeX copyright and > the Lesser GNU General Public License. > For more information about these matters, see the file > named COPYING and the XeTeX source. > Primary author of XeTeX: Jonathan Kew. > Compiled with ICU version 4.6 [with modifications for XeTeX] > Compiled with zlib version 1.2.5; using 1.2.5 > Compiled with FreeType2 version 2.4.6; using 2.4.6 > Compiled with fontconfig version 2.8.0; using 2.8.0 > Compiled with libpng version 1.4.8; using 1.4.8 > Compiled with poppler version 0.16.6 > > $ file /opt/local/bin/xetex > /opt/local/bin/xetex: Mach-O 64-bit executable x86_64 > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Trying to build microtype-aware xetex
Hi Herbert, You are right their is font library that is deprecated and only allows xe(l)tex to be built 32-bit! This will have to change as the Mac world has going 64-bit. Yes, you can run 32-bit programs under Lion, but it also comes at a performance price. Anyone know exactly which library and how hard it would be to refractor or rewrite? regards Keith. Am 29.08.2011 um 03:30 schrieb Herbert Schulz: > > Howdy, > > Were you trying to build a 64bit xetex? I believe (folks, please correct me > if I'm wrong) there is a problem building 64bit (some framework is 32bit > only?) and the xetex for Mac (even the one in x86_64-darwin) is actually > 32bit. > > Good Luck, > > Herb Schulz > (herbs at wideopenwest dot com) > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] rtl Longtable package
Hi All, Although this is ended. There is another interpretation of the use of "quick reply" quick can, also, mean brief/short !! That is how I read it. On the other side, Heba said a quick reply would be "highly appreciated". Which is very polite, even I he needed a response very fast! Language is so much fun. My apologies. Keith. Am 25.08.2011 um 23:36 schrieb Alan Munn: > On Aug 25, 2011, at 4:55 PM, Philip TAYLOR (Webmaster, Ret'd) wrote: > >> >> >> Karljurgen Feuerherm wrote: >> >>> I suspect this is more an attempt to be extra polite which didn't come out >>> perfectly in English than to be pushy or demanding... it's presumably >>> understood that list subscribers try very hard to be helpful, and that any >>> help offered comes at the expense of the one helping. >> >> I agree : I felt that Alan's parenthetical response was >> not really called for. > > Fair enough. My apologies to the Heba. I hope the answer helps, though. > > Alan > > > -- > Alan Munn > am...@gmx.com > > > > > > > > -- > 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] Xetex TexLife and fc-cache
Hi Nicolas, Normally, XeTeX does not take that long to start up or run! It would seem to me that your system and web-server is set-up wrong. There are other possibilities for the problems you are experiencing. Either way, I believe you problem has nothing to do with XeTeX. Sorry. regards Keith. Am 10.08.2011 um 10:03 schrieb Nicolás Hatcher: > Hi All (again): > > It seems I was guessing too much. Perhaps my problem is not fc-cache. > What happens is that with any new day the first xelatex run is extremely slow. > Could be 5 minutes before pass the line > This is XeTeX, Version ... > I am doing a system that produces pdf documents on demand from a website. I > cannot ask the user to wait "sometimes" 5 minutes. > I know is not fc-cache because I substituted it with a dummy file and the > problem is still there. > What does XeTeX before launching? > Any pointers to the source code so I can investigate myself? > Would the same problem arise on MiKTeX? > > Again, thanks for your help in advance, > > Nicolás > > 2011/8/8 Nicolás Hatcher > Hi all, > > It seems that xelatex runs fc-cache in windows in Texlive 2010 once everyday > or so. > anyone knows how to disable that option? > Thanks in advance. > > Nicolás Hatcher > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Loading fonts from a common server or http URL
Hi Matthew, I was not talking about implementing a full http-client. As Phil has pointed out the texlive code base is not the newest nor very modern. The whole world benefit from a complete rewrite, but that is another story. Things have come a long way. There are always pros and cons to things. Like I said, loading non installed packages on the fly is a intelligent feature. Personally, I have no problem with a full texlive install, but that is because that is the way things are. regards Keith. Am 22.06.2011 um 15:27 schrieb msk...@ansuz.sooke.bc.ca: > On Wed, 22 Jun 2011, Keith J. Schultz wrote: >> 2) A program can open any/retrieve any file on a server >> using http. all it needs to do is speak http! > > While we're at it, let's add a spelling checker, SQL database backend, and > multilingual thesaurus to TeX. Also a Space Invaders mini-game that you > can play while you wait for your document to compile. And let's make all > these things work identically on all platforms, of course. > > I don't think that network communication is reasonably part of what TeX is > for, and although I recognize that some current extended-TeX projects > already include it because it was part of languages or libraries they > imported, and there may be some EXTREMELY UNUSUAL situations (such as > compiling documents locally on a small tablet) where remote file loading > is useful, I hope there isn't a large effort made to add this as a basic > widely-used feature. I already have enough trouble when people send me > documents with files missing, without also adding in the compatibility and > security nightmares of "Oh, my document won't compile, or won't compile > the same way today as yesterday, because of issues on a remote server I > don't control." Remember that repeatability is a basic part of the > mission of TeX, and repeatability simply no longer exists as soon as your > document depends on remote files. > > The existing \write18 feature allows documents to execute arbitrary > programs, and there's free software available for all currently popular > operating systems to automatically download files as needed. (e.g. > HTTP-client filesystems for FUSE, under Linux and Mac OS.) So people who > do need to make their documents access the network during compilation, > already can. I don't think it should be encouraged, though, nor that TeX > should have an entire HTTP client built into it (which is NOT a trivial > project if you want it to be cross-platform and actually work) just to > make it easier for users to destroy the repeatability of TeX compilation. > -- > Matthew Skala > msk...@ansuz.sooke.bc.ca People before principles. > http://ansuz.sooke.bc.ca/ > > > -- > 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] Loading fonts from a common server or http URL
Am 22.06.2011 um 10:36 schrieb Philip TAYLOR (Webmaster, Ret'd): > > > Keith J. Schultz wrote: > >> The problem is not the OS or "filing system". It is the programs. >> 1) If you have a remote server mounted all you need >> is the mount point plus the path to the file. Standard >> on all OSes I know. > > I am not convinced that the CTAN backbone supports (or > would want to support) "remote mounting". I doubt it either! But, it could be done on a local server or for a group which wishes to collaborate. Also, there could be read only mounts! Sorry, getting OT here! > >> 2) A program can open any/retrieve any file on a server >> using http. all it needs to do is speak http! >> >> Technically this is not a problem. > > Agreed. > >> I believe XeTex et al. should be able to handle 1) without any problems. > > See above ! >> >> 2) would require code to be added to retrieve the file, cache it, and access >> it >> add throw it any when done. A waste of bandwidth in my opinion. There are >> other cavets to consider. > > In my opinion, this is the way of the future. It is ludicrous > that we all have to create our own virtual CTAN mirrors. Far > better to evolve a methodology that will, entirely transparently, > use a local copy as first choice; fetch (via http) a remote copy > and make it local, as second choice; and (3) offer a configuration > option to check whether the remote copy is more recent than the > local and if so, fetch it (and install it locally) automatically > when that file is next required. Well, in a sense with tlmgr we already have this. Only, it is manual. Could write a cron script to run tlmgr to keep the system uptodate. Automatic downloads of missing parts, would require a major rewrite. There is no internal infrastructure in place for this kind of system. > > A TeX Live installation should, IMVHO, start as small as possible > and grow by accretion. Bulk installs should be seen as yesterday's > technology, install-on-first-demand as the way of the future. I agree that it would be a nice feature, especially in the light of tablets with their minimal storage capacities. On my laptop I am happy having a full installation. Do not need to worry, if I have net access. regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Loading fonts from a common server or http URL
Hi Everybody,
The problem is not the OS or "filing system". It is the programs.
1) If you have a remote server mounted all you need
is the mount point plus the path to the file. Standard
on all OSes I know.
2) A program can open any/retrieve any file on a server
using http. all it needs to do is speak http!
Technically this is not a problem.
I believe XeTex et al. should be able to handle 1) without any problems.
2) would require code to be added to retrieve the file, cache it, and access it
add throw it any when done. A waste of bandwidth in my opinion. There are
other cavets to consider.
A better way is to build your own repository and access that. The only sense
the http approach would have is if you have limited storage!
regards
Keith.
Am 22.06.2011 um 09:28 schrieb Philip TAYLOR (Webmaster, Ret'd):
>
>
> Venkatesan. S.K. (TNQ) wrote:
>
>> It is more a *fontspec* question and may be it has wider scope...
>> Is it possible to load fonts from http URLs?
>> i.e., can I do this:
>> \fontspec{http://www.ctan.org/public/fonts/STIXGeneral.otf}.
>
> I think it is more of a [Xe]TeX-engine question, to be honest,
> and one that has never really been satisfactorily resolved.
> Because just as you might want to write :
>
> > \fontspec {http://www.ctan.org/public/fonts/STIXGeneral.otf}.
>
> you might also want to write
>
> \usepackage {http://example.org/LaTeX/Classes/keyval.cls}
>
> Indeed, anywhere in [La][Xe]TeX [1] that you want to open a file for
> reading (be it font file, source file, data file or whatever),
> it would be nice if that file could be on a remote server and
> fetched using http.
>
> Unfortunately I am not aware of any implementation of [Xe]TeX
> that supports this; probably the most likely candidate would
> be LuaTeX (Taco cc'd) but I do not think that even LuaTeX
> yet supports this concept.
>
> Philip Taylor
>
> [1] Or indeed, anywhere at all within your PC/Macintosh/Unix box/whatever.
> The problem is not unique to TeX, and it is not at all clear to me
> why filing systems have not yet evolved to allow remote http-served
> files to be read-accessed using the same interface as local files.
>
>
> --
> 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] Persian verus Farsi
Hi Phil, I can not much about Persian, Farsi, but the Americans use to speak acedenmically "American English", which in colloquial American was referred to as English. Today, American is the widespread term in Acedemica. Québécois is definitely is not French. regards Keith. Am 10.06.2011 um 15:43 schrieb Philip TAYLOR (Webmaster, Ret'd): > > > Vafa Khalighi wrote: >> >> A while ago, I insisted on using the word "Persian" instead "Farsi". My >> friend, Shapour Suren-Pahlav from the circle of ancient Iranian studies has >> written an article about this. You can see his article here: >> http://www.cais-soas.com/CAIS/Languages/persian_not_farsi.htm > > Well, yes : but is it any worse than the Americans describing > their language as "English" ?! At least the French-speaking > residents of Québec have the decency to call their language > "Québécois" and not try to pass it off as French :-) > > Philip Taylor > > > -- > 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] Don't update to Mac OS X 10.6.7
Hi All, Have anybody with problems have the 64-bit kernal running! I am as I prepare for the transition to Lion! So far I do not have any problems with any of the programs i use! So it just not be apples fault! then again! regards Keith. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Don't update to Mac OS X 10.6.7
HI, I am on 10.6.7 and do not have any problems with fonts and printing! I believe their is a simple fix. Delete the font caches. I can not remeber the the source, but deleting the font cache seems to fix the problem! regards Keith. Am 01.04.2011 um 21:00 schrieb Mojca Miklavec: > Hello, > > I'm sorry for cross-posting, but this issue is a really nasty one (and > might come too late for some). If you use OpenType fonts in your TeX > documents, don't update your Mac OS X unless you want to have some > serious fun with printing ... > > http://reviews.cnet.com/8301-13727_7-20048314-263.html > http://discussions.apple.com/thread.jspa?threadID=2792142 > http://discussions.apple.com/thread.jspa?threadID=2791830 > > ... a workaround that worked for me (for PostScript printers only) was > the following: I used > http://localhost:631/help > for help and ended up doing > lpstat -p > to get printer name and then > lp -d some_very_weird_printer_name_ myfile.pdf > to send the file to a PostScript printer. > > I wasn't sure whether it was an OS issue or LuaTeX issue (I updated > both), but Florian on ntg-context mailing list posted the above links > which most probably makes XeTeX users vulnerable as well. > > Mojca > > > -- > 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] Proper way to set up OT Features
Hi David, Are You joking? Seriously! All I can say is HAL == IBM! Now == Opx!! Please do not be offended. But, it does seem more than a coincidence! A shift of one! Sorry, no help. regards Keith Am 15.02.2011 um 04:49 schrieb David J. Perry: > > WinVista SP2, MiKTeX 2.9 > Font generally seems OK with Word and OpenOffice Writer, although neither > supports OT features so I can't test that aspect of things. However, the > font fails completely in XeLaTex; "Now" appears as "Opx". Same exact font > file, folks. I already tried uninstalling and reinstalling MiKTeX; no > improvement. You can see why I am going crazy with this. > -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Please HeLp: I get this error compiling my Thesis
What is your preamble? regards Keith. Am 14.12.2010 um 05:58 schrieb Alan Jones: > > Hi: > > I get this error compiling my thesis. I have TexLive 2008 on Debian Lenny. > > ! Package ifpdf Error: Name clash, \ifpdf is already defined. > > See the ifpdf package documentation for explanation. > Type H for immediate help. > ... > > > Thanks, > > Kind Regards, > Alan > > > -- > 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] Setting greek letters in cmtt with XeTeX on OS X
Hi Rodney, Look into the unicode-math package and the unicode math fonts. regards Keith. Am 18.10.2010 um 08:41 schrieb Rodney Polkinghorne: > Dear list > > Has anyone used lcm with XeTeX? If so, how do you map greek letters > in the XeTeX source to the encodings used in the lcm font files? > > I'm writing a program to simulate clouds of trapped atoms. It > involves some complicated equations, and I'm using noweb to combine > the mathematical derivations with the fortran code to solve them. The > code uses greek letters as variables, to be consistent with the > mathematics. > > I'm currently setting the text and equations in Computer Modern, and > the code in Courier New. That works, but it's ugly. I'd like to set > the code in Computer Modern Typewriter, but the sticking point is > those greek letters. > > I downloaded the Open Type lcm files, and installed them on my OS X > box using the Font Book program. That was easy. Then I realised that > lcm lacks greek letters. I downloaded the cm-lgc fonts, which are > supposed to include a greek version of cmtt. However, these only come > as Type 1 files, which Font Book refuses to touch. I haven't figured > out how to use them with XeTeX, either. > > Am I making this harder than it needs to be? I'm not that attached to > Computer Modern, and maybe there are other fonts where this would > simply work. > > Thanks for any help you can offer. > > Rodney Polkinghorne > > > -- > 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] Error with latest expl3?
Hi Will, Do not worry about it. These things do happen and all is work in progress. Also, it it was that easy we would not need you, and appreciate your hard work so much!! regards Keith. Am 17.10.2010 um 07:40 schrieb Will Robertson: > > Well, we try to avoid these problems but we've recently had a bad run. For > me, I'm trying to do too much so I'm making careless errors to often for my > liking. Sorry for the inconvenience, -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Localized XeLaTeX / greek XeLaTeX
Well since the xetex engine/binary is modified one can allow it to accept an optional line before \documentclass for setting the "language". If it is there change "language" if not assume "normal". regards Keith. Am 15.10.2010 um 15:45 schrieb Philip Taylor (Webmaster, Ret'd): > > > Alexandros Gotsis wrote: > > > > A suggestion : suppose that, for some future version of XeTeX, > the first line of the file was treated specially if it started > (say) %! (or some analogous but currently unused sequence of > characters that can be found in most keyboards without > requiring language switching). > > And suppose that following that %! (or whatever) was > expected to occur the name of the language in which > the remainder of the document was written, expressed > (of course) in Unicode (e.g., %! ελληνική). > > This would then (I think) solve 50% of your problem, > in that your daughter could then write the entire > contents of the file in Greek, including the Greek > word for "documentclass" (which I regret I do not know). > > This would not of itself cause XeLaTeX to recognise > (say) \κατηγορίαεγγράφου as meaning \documentclass, > but as I have pointed out in a previous message, > the full solution to that side of things is > distinctly murky ... > > Would this, in some way, and if XeLaTeX could make > use of this information, be a step forwards ? > > Philip Taylor > > > -- > 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] Localised [Xe][La]TeX (was : Localized XeLaTeX (was : Greek XeLaTeX))
Nice examples.
Am 15.10.2010 um 15:29 schrieb Philip Taylor (Webmaster, Ret'd):
>
> Keith, I don't see enough in your answer to enable me to understand
> how you propose to resolve what seem to me to be very serious
> problems of semantic ambiguity. Let me give a simple example,
> using a fictitious language (Mekon) that use the basic latin character set.
>
> Mekon defines the following translations :
>
> \efg = \def
> \emph = \centerline
> \foe = \end
> \joqvu = \input
>
>
> File-1 contains :
>
> %!Markup-language = Mekon
> \joqvu File-2
> \emph {Ifmmp xpsme !}
> \foe
>
> File-2 contains :
>
> %!Markup-language = Mekon
> \efg \emph #1{}
> \end
>
> When the processing engine encounters \emph at line 3 of File-1,
> should it translate \emph into \centerline, as required by the
> translation rules for Mekon, or should it leave it untranslated
> so that it can reference the definition of \emph that occurs
> at line 2 of File-2 ?
That one is simple it should translate, because it was defined.
Naturally, it is a bad idea to overload like this.
But, since it is overload one should translate.
If you wanted the "normal" emphasis then use:
%!Markup-language = Mekon
\joqvu File-2
%!Markup-language = normal
\emph {Ifmmp xpsme !}
%!Markup-language = Mekon
\foe
> And when that same processing engine is called upon to process
> File-2, should it translate \emph as \centerline, so that it
> is \centerline that is being defined, or should it leave it
> untranslated and therefore it is \emph that is being defined ?
O.K. This is somewhat complex.
The way I look at it.
1) Markup language in both cases is set to Mekon
2) When the parser finds \emph iot translate it to \centerline
\efg \emph #1{}becomes \def \centerline #1{}
3) All actions are to take place in the "normal" markup that is
why it is translated
before being processed.
4) It would parse O.K. since it did not find a translation for
\end
and thereby reverting to the "normal" \end
I agree that this seems complex, but is logical. and one has to be
aware or in which
"language" one is.
Now, lets see what happens if File-2 look different.
File-2 contains :
\def \emph #1{}
\end
Here the result would be the same as, that \centerline is affected,
since "Mekon" is still active.
Now, if File-2 look like
File-2 contains :
%!Markup-language = normal
\def \emph #1{}
\end
Then, we have the normal tex effect.
BUT, with File-1 containing :
%!Markup-language = Mekon
\joqvu File-2
\emph {Ifmmp xpsme !}
\foe
\emph stays \emph as the "language" is normal.
Furthermore, \foe will trigger a undefined command error, since
"normal" is active, due to
the switch in File-2. But, such global scope is the way of TeX.
>
> In other words, can we, with 100% precision, define in which
> contexts strings should be translated and in which contexts they
> should not, bearing in mind the fundamental ability of TeX
> programs to change the meaning of virtually everything on
> the fly ?
Yes, but you have to know in what "language" mode you are in.
Like you mentioned this is a semantical problem and off the bat I can
not
think of any way to catch a semantical error. I believe TeX can not do
this.
regards
Keith.
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
