Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id s4LDEJ56002281 for ; Wed, 21 May 2014 15:14:20 +0200 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by mx-ha.gmx.net (mxgmx101) with ESMTPS (Nemesis) id 0MHIid-1Wai0c028x-00E2Md for ; Wed, 21 May 2014 15:14:13 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id s4LD9jPE004098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2014 15:11:41 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s4LBY6dw024600; Wed, 21 May 2014 15:07:55 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 11070254 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 21 May 2014 15:07:27 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s4LD7REk019215 for ; Wed, 21 May 2014 15:07:27 +0200 Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s4LD5rR5026711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 21 May 2014 15:05:57 +0200 Received: from [192.156.217.104] (86.188.197.189) by AM3PR05MB356.eurprd05.prod.outlook.com (10.242.247.26) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 21 May 2014 13:05:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 References: <537C887C.1000009@nag.co.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed X-Originating-IP: [86.188.197.189] X-ClientProxiedBy: DB4PR02CA0045.eurprd02.prod.outlook.com (10.242.174.173) To AM3PR05MB356.eurprd05.prod.outlook.com (10.242.247.26) X-Forefront-PRVS: 0218A015FA X-Forefront-Antispam-Report: SFV:NSPM;SFS:(6009001)(6049001)(428001)(189002)(199002)(24454002)(479174003)(377454003)(51704005)(87266999)(50986999)(19580395003)(47776003)(83506001)(80316001)(83072002)(85852003)(54356999)(36756003)(15975445006)(76176999)(80022001)(23746002)(20776003)(19580405001)(83322001)(102836001)(81342001)(101416001)(81542001)(64126003)(21056001)(65816999)(87976001)(221733001)(74826001)(50466002)(99396002)(59896001)(77982001)(79102001)(33656002)(4396001)(66066001)(42186004)(74662001)(76482001)(64706001)(15202345003)(65956001)(92726001)(46102001)(74502001)(74482001);DIR:OUT;SFP:;SCL:1;SRVR:AM3PR05MB356;H:[192.156.217.104];FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;A:1;LANG:en; Received-SPF: None (: nag.co.uk does not designate permitted sender hosts) X-OriginatorOrg: nag.co.uk Message-ID: <537CA4AE.3050605@nag.co.uk> Date: Wed, 21 May 2014 14:05:50 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: David Carlisle Subject: Re: Unicode math To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by relay.uni-heidelberg.de id s4LD9jPE004098 Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:6QsZ+qYrS3U=:UqO4QrmsmMYfSueYGu/YC1GdUF NA8d7uo2Bnzqq6A9YgpaNCa+Et/HqBSvi2FUJ2048184lm+RWz3+/yr72W37eYtxdo3ZKBpwf ixtrOQxamJKiCP5HlJF9u8mSKfU6GCBCr6fbTglFX1J9Qg9ky5AMAJeKDUEzyuvrG+QYLFYVd aL8LKuG+m08W7QVrebf3EQ/YoOhIOYGMokrvTAn2BzuKUamdsm6dNNuQNkuiQrTtNOj86FFRY T0Zs+661pOA5ny/9vztUX4KW+hT4hnnTKYnoMkL6xbhKXH0ybqxASEodSKAi/Eockt3HvSj/2 y/Lmnbo7EodSd7eQqoCtzXund5SmYPFPQFjsH4HT5U7PFI0dJfLPpw+sGQh3t99IPBttPGKYs ub4XMvF6SxRBbn5pBuWYa2azmswkdddfVFJGAagBTbLtXVS08PIicALaOm2DcLZn9Vzbfh/He BlHaSjjEKCwByRPrVXrQu+iEAuInnkRaLpfai1ZIj/Uvmd4xl+bkTP+6WMnjuuS0YavLAZbM/ OYH6qQPL5AAWbTFl49e08e+ktM9YGz8pU2jft2118UwaMykPmk8/h48A3w9UDyDEe9Xj2suPR Z+yEbnoiKCwq48EB7CUiEcz7JTNRMhiov01wzBWzOaTmZhiKsJBBUWmN8XxG3D69IyYXFd70W Yy9KBNp3ns92RKuw8jxrmmaZHxApcfed/rmWG4+JQmR2lbT5/WmAYMuL4p/vLi1mwQBX5YmOD yxQaVAqu3Mfc0x5rHaTANE6iVZHkmqjUHEPXxezMPoHf5G7pY8kvxyeQRegSbdj5K96043dt5 UCCchmIfOXzV6DSWOBN+QuHTkQj4tuFxP94Q0A5tMSqMApFRLfzCrNhPv28dNFsEDrSgbzSN7 1ZqIi5n9SDdfvSoARwnNottCy/2vISdoMc5tg+2EXDBy3y4y1NvDcOU2Mlpp2Aj3TFL2O3dWQ JVLx6q5f/y/c1LcBpAs9BFOz453iW4+viRI0FBoZhDUVZr4eW6b9X9UJa6h+OXi/5d0jIg8mx 55lq5yqhnFzAue4QbT+SSO7P/ZZseW6qx2gU55JtaxqQpRSIEtfKWxmHbIjGBdsI4WrQ0aEBC dJYk3KpdQ1+eq6cROYpsbEPACO14ojH/fOuzvAsfC+P15vCxC8rmYowXBAtIViX5dPyyRc1Lx pQ9nsDf9hh1CdxNCmrUxZyOapa06ngsTExsTTi5FehkZmV42eW7MDHo0k6PYROsUhpg3YC74R yOkGMIABqTFvxwwX5mkoC7f9TwJtQp/2ElzhJjXXqmUGiVXsc744maOZtHpaJcwx3VXJfDSUd GmG87FoNiN+muAmQ70o3vqpb4HNWBUPxYnd7uZtBl1XTVoJNDt1IIK6myVFTTwZ5MphafoApF oShw9OiU3liJPv7TJr/53svcHRVzMdk9yHLw8MY3q636pOKRTSpUnix/4hQ6qTq+L9lLp2BKz dpTuUOigjd85FX4NZ0suXudIRXWYXUoAXqykTsBhbneVXi3fhJMVTW/h+xZxl8r+6AwvdHm0X 7DFtoyaFJyWZNaC5njzL70+8KLy8R8A+Sw0+gE2Kn X-UI-Loop:V01:3AFoXI7SLxE=:KlRtyhTuXQ7IemAq+v9edQFDz/TvAX/dee+L/FoHfXw= Status: R X-Status: X-Keywords: X-UID: 7435 On 21/05/2014 13:41, Will Robertson wrote: > On 21 May 2014, at 8:35 pm, David Carlisle wrote: > >> On 21/05/2014 11:49, Will Robertson wrote: >>> On 20 May 2014, at 11:34 pm, Ulrike Fischer >>> >>> wrote: >>> >>> >>>> So in my opinion the current \mathbf-etc setup in unicode-math >>>> actually did the right thing and improved the standard >>>> \math-commands. >>>> >>> I=92m replying out of order, but I=92m still inclined to agree with y= ou here :) >>> The big problem was not handling \mathit properly. >>> >> or at least the problem is more apparent for italic as the differences= between >> math and text setting are more glaring in that case:-) > Well, I think from the foregoing discussing (correct me if I=92m wrong = on this!) that we all roughly agree that a suitable OpenType math font wi= th bold glyphs in plane 1 will still be a sensible default for \mathbf, a= lbeit with an obvious override possible (both as a package option and at = math-font-load time) when a =93text=94 bold font is desired instead for m= ulti-letter identifiers. I think it should be available as a possibility, but not as a default=20 (and not required very often). You need to use a text font for multi-letter identifier case and it=20 would look odd if single and two letter identifiers were coming from separate fonts, so most of the time you need to use the same font for the single letter=20 case. If a package is setting up a font family for which there is no natural=20 bold font, and for which the base font has bold glyphs in the unicode slots then obviously it makes sense to use that as the default for that font=20 family. Or if an end user knows that in a particular document that \mathbf is=20 only used with single letter arguments and wants to use the base font, there=20 should be an easy way to select that, but this has to be a user option given the=20 usage in a particular document, so not a default. > > \mathit is just wrong as it currently stands. > > >>> It has been possible for a long time to select a text font for a math= alphabet in unicode-math, but this feature was probably not documented v= ery well. >>> If you try to select a particular unicode range such as \mathbfup and= a font simply doesn=92t have it (well, it only checks =93A=94 I think), = the remapping doesn=92t occur and you get the ascii-range glyphs: >>> >> Yes, although I think what's needed is an explicit way to do this rath= er than relying on heuristics > Agreed for sure. > > >> for example while answering a tex.sx question I wanted to use rsfs (or= euler) for script in addition or instead of >> the script in stix because well just because that's what the question = asked for, and it seemed that the easiest way >> currently is to use \mathup{\euler{A B C to disable the mathcode mappi= ng which works but looks a bit odd. > Most certainly, this is not what we should be asking users to do. > This (arbitrary \mathXYZ alphabet support) was always in the works but = time got away from me. > > Cheers, > Will > Yes I didn't mean that that was ideal markup (and I may have missed=20 something better in the existing code) but for a tex.sx answer where I didn't want to be redefining internals=20 it seemed at least an approach that I could give some explanation of why it worked. I just mentioned it as it seemed relevant., in that the functionality=20 was requested and is, as you say, basically already available in unicode-math. http://tex.stackexchange.com/questions/131866/is-it-possible-to-add-new-a= lphabets-to-unicode-math/169630#169630 hope what I said there is true:-) I feel I should say as I seem to be doing more than my fair share of=20 the "complaints" that unicode-math does a pretty impressive job of taming otf math fonts=20 and bringing them in to TeX it's only the surface syntax that we are arguing about really:-) David