From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE,URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8814 invoked from network); 18 Jun 2023 19:56:44 -0000 Received: from zapf.ntg.nl (5.39.185.232) by inbox.vuxu.org with ESMTPUTF8; 18 Jun 2023 19:56:44 -0000 Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id 098DC721E; Sun, 18 Jun 2023 21:56:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at zapf.ntg.nl Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfFWfTVYCExr; Sun, 18 Jun 2023 21:56:15 +0200 (CEST) Received: from zapf.ntg.nl (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id A1B3371C4; Sun, 18 Jun 2023 21:56:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id EADBD71C4 for ; Sun, 18 Jun 2023 21:56:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at zapf.ntg.nl Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3PkrNR0MuVp for ; Sun, 18 Jun 2023 21:56:12 +0200 (CEST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=195.121.94.167; helo=ewsoutbound.kpnmail.nl; envelope-from=j.hagen@xs4all.nl; receiver= Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.167]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by zapf.ntg.nl (Postfix) with ESMTPS id B0BAC7167 for ; Sun, 18 Jun 2023 21:56:12 +0200 (CEST) X-KPN-MessageId: 2bc8c6c4-0e12-11ee-889e-005056abbe64 Received: from smtp.kpnmail.nl (unknown [10.31.155.39]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 2bc8c6c4-0e12-11ee-889e-005056abbe64; Sun, 18 Jun 2023 21:56:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=xs4all01; h=content-type:from:to:subject:mime-version:date:message-id; bh=Qen1tvphrtqAUOepZZNaykz7SZfp13LSttsWR1geO5A=; b=HGxU5r9uT+g96+mX/g3bnlnhQ2Ys79n8eTISe5vFUfpJucfYg3gUJYv+N7r9laspo1kfkOelxTfbr 6R+SORtNUo8A34S/7lAu/z9fC41mkr2TSTaqUyLql6yuoRwdaGONwfLqjI6yZqLIzJUa38xnaGPDc/ SeReOBdEs8lA1QyhcMLzwmyrhOjOaWqr6IweXsl0295Yv9zmOF2LcVXNoYJR29XLYNCny0xNiD4sdf K57a2vaXE9b+yMijZ8U6Zzng+LNbaIBvXuxopyiBeANNJJ1iOAOm49Y59Wa77ebAckTO9SzCrK8PVV TmRqN7d11V9+ft1T0BlQBDVngctFi8A== X-KPN-MID: 33|T9S3JSleu2nurXAa+MX4tszVBJ5B1BhF1fa+59z5uJ6z0bL2+UWopuRtRZ71pqw qz1ilvT97+oE/eInQ0BMghV5hTi+jfrM4hFnF22mwFcE= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|Ih5IYQiJyS+bdAwHN0zNSz5BpEPkdo0VFeo+mXwHtV0Y0w+GqSI7WipkNZ4polj 9853VnpS92ZUMtHEQCElX2w== X-Originating-IP: 213.125.29.162 Received: from [10.100.1.105] (d57d1da2.static.ziggozakelijk.nl [213.125.29.162]) by smtp.xs4all.nl (Halon) with ESMTPSA id 2c640ec4-0e12-11ee-bd07-005056ab7447; Sun, 18 Jun 2023 21:56:11 +0200 (CEST) Message-ID: <4dc6e2b5-45e0-91b7-d23a-70c099a0c873@xs4all.nl> Date: Sun, 18 Jun 2023 21:56:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Content-Language: en-US To: ntg-context@ntg.nl References: <161B7310-CACD-4112-9715-4C6F8AFD9F95@rna.nl> <07621a2f-f918-1a41-2e9b-51e07480d12b@xs4all.nl> In-Reply-To: Subject: Re: [NTG-context] Off topic: Does a 'free for commercial use' flared-sans font exist in the world? X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.1.38 Precedence: list List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Hans Hagen via ntg-context Reply-To: mailing list for ConTeXt users Cc: Hans Hagen Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntg-context-bounces@ntg.nl Sender: "ntg-context" On 6/18/2023 8:37 PM, Carlos via ntg-context wrote: > On Sat, Jun 17, 2023 at 06:53:06PM +0200, Hans Hagen via ntg-context wrote: > >> On 6/17/2023 2:06 AM, linguafalsa--- via ntg-context wrote: >>> On Fri, Jun 16, 2023 at 06:35:49PM +0200, Gerben Wierda via ntg-context wrote: >>>> I know this is off topic, but I suspect this community is actually one of the best places to find an answer. >>>> >>> >>> It is the best community. And I tell you what. >>> >>> What happened is that all TeX engines have neglected fonts from the beginning. >> >> Really? When tex showed up digital font technology was pretty much in flux. >> And, with metafont being part of the tex ecosystem, one can argue that tex >> was quite innovative too. > > Ecosystem. I would be very careful by including an ecosystem there. > Yes. Yes. The TeX ecosystem is obviously part of TeX but is not part > of the ecosystem of fonts either. And what is done on ecosystems > can either benefit or affect ecosystems greatly. And it's a known > trait that humans have been known for having more of a flock group > mentality for no apparent rationally-based reasons than just being > themselves making these decisions/following instincts or whatever > and not because of a particular ecosystem, or for the benefit of the latter. With ecosystemn I mean: tex, metafont, cmr fonts, all kind of tools ... evolving into more engines, more fonts, macro packages, distributions, user groups and use group journals, meetings etc > And the above does not imply, bear with me here, that metafont was > not innovative, but it can be argued that without TeX there is no > metafont, so no room is left for errors either. So, yes, it must be > innovative. It has to be. There had to be metafont because there was not much else that could provide what tex needed (at that time). >> Potscript and its fonts came aroudn at the same time and were rather closed >> technologies. But as soon possible backend drivers (also part of the tex >> ecosystem) kicked in. >> >> Then we got virtual fonts which enhanced tex's capabilities. >> >>>> I really like Optima, and what I really like about it is the 'flared style'. >>>> >>>> But I would like to move to a flared-sans font that gives me more licensing freedom. I haven't been able to find one after extensive searching. The only one who were reasonably priced (not free) were the URW Classico ones in Adobe Creative Cloud, but those can only be used in Adobe programs like InDesign (and not TeX). >>>> >>> >>> Licensing freedom is an oxymoron. There's no freedom in licensing. >>> Only greed. >>> >>> The only extension engine that at one point had a plan in mind, >>> or most of the bases covered in this regard was Omega. >> >> One needs morr than plans. Afaik omega was more about input processing and >> th efont part was mostly going beyond 8 bit fonts but i might have missed >> something (omega was never productin ready). > > Notwithstanding the intricacies/details of what may have actually > happened with its short lifespan I think it's more than clear the lack > of support behind it. I'm not going to delve into what exactly caused > its demise or if it was simply the after effect of other projects > that contributed to it. It's irrelevant. Hm, its time span was not that short ... I first heard of omega at the eurotex meeting in arnhem where also etex was discussed (and you dont'want me to cite things said there) .. in successive years there have been announcemnts etc. However, for an engine to be used it must work reliable and guiseppes 'aleph' was basically a variant of omega that also had etex on board. In fact, that was supported in context mkii (and some used it because of the input processor which i think was the more innovative thing in omega but i never dived into it, other users did) It makes no sense to discuss into all this as all teams involved in engines have published in user group journals or presented plans at meetings. Also keep in mind that we're talking frontend here; omega is dvi based so like regular tex and etex whatever it does with fonts is not really related to the engine bu tup to the backend: the engine only needs metrics (omega extended tfm into ofm for that). pdftex brought a pdf backend, xetex pipes into a dvi backend, luatex has a pdf backend built in; (nts being related to etec never took of also because it was not that useable and in the meantime pdftex had taken over); there are afaik some very useable japanese tex engines; the fact that dvi survived was due to dvipdfmx development > But stand by for a second. I look forward to your quick witted answers. But hear me > out > > Suppose that on my prior message I was referring indeed to 'mkii' and > not to 'omega' > > And also suppose for a second that the term 'omega' is to be replaced > with 'mkii' on your reply accordingly > > After careful observation the resemblance is quite possibly identical, > isn't it? and it could also inarguably apply to the circumstances as > well. Don't you think? no it isn't, its building upon hat is there: mkii -> mkiv -> mkxl (pdf)tex -> luatex -> luametatex > I mean, it's like comparing oranges with apples, and mkii with mkiv and > mkvi and so forth mkii is there, it works, stil used, quite stable etc ... it's not some half-way experiment and mkiv is just a follow up on it as is mkxl on mkiv > If you were to tell me then, that mkii for instance was not aimed > as an input processing I can almos assure its falsiliability is written > all over, even before the sentence is processed and thought out loud > by you. I don't understand (omega input processing is not reading files as tex does, but juggling sequences of characters (tokens) into other sequences suitable for rendering from fonts ... a bit like contextual substitution does in open type). That might eventually in the engine lead to mapping glyphs or snippets but the resulting node lists is what the engine then carries on. > Bottom line is that the production-ready part is an obvious byproduct > of its short lifespan, but one cannot be making the claim (false as > would have been seen later, because omega carbon footprint lasted more > on books than on shelves really, not for selling out fast but rather > discontinued quickly) and that its goal was solely within this input > processing spectrum. Because it wasn't. hm, there are a few things that could push omega: a special input processor (for scripts that need it, i think that was the evolving bit), large registers ranges (done slightly different than etex), and directionality (in retrospect only a few made sense which was admitted by one of the authors; that bit combined with local boxes became part of luatex). The mathml stuff in omega never really went operational i think. But, i think there were more ambitious plans esp as i remember talks about media and multiple dimensions and languages and so but there we also have a chicken egg situation: one reason why luatex works is that it evolved parallel to context so it got used and functionality got tested; there were also (i think) more plans with etex, but as that go stalled it also stayed with one version and a few things added; pdftex had more impact because it was really used (e.g. in mkii) immediately. > Or heck So there is a lot involved in engines etc being accepted, a dedicated user base being one of them (could be a few users). A small community like the context one cannot simply jump on any engine. It also depends on needs. In the end I think that etex an domega both beign around as possible extensions at least kept the users open minded about extensions. > or heck. Let's go even further. By making the dubious assertion > that we've been built with noses to hold our eyeglasses lest these > eyeglasses fall off while reading, or that we've been built with ears > to hold pencils and pens in the ears while thinking and writing. > > For crying out loud. >> >> It is xetex that hooked into opentype although pdftex can actually deal with >> truetype fonts to some extend. Before there was something 'opentype' we had >> two competing but similar technologies. And it took a while before it was >> even clear how to interpre the specification (also think about reverse >> engeneering fonts and heuristics and ... bugs or features ...). TeX was >> always pretty fast in picking up new stuff (maybe users less so). >> >>> When it came to commercial fonts the plan of action ahead was by >>> including PFC data on these very same commercial fonts that would >>> benefit primarily its opentype versions in the long run. >> >> What is PFC data? > > The glyph containers on a table-based SFNT format So just shapes or pieces of shapes? >>> What do you have right now? Opentype fonts only. Sure. Quality can be >>> even the same than its type1 counterpart, and at times not so much >>> according so some folks that have bothered to go the extra length in >>> making the most accurate comparison that's available between them two. >> >> For most fonts it's just 'more shapes' which then also leads to more >> ligatures, kerns etc btu that is already nice. And when fonts lack something >> we can always tweak them (runtime). > > But it's not about kerns nor ligatures but hinting Hans, hinting, and > that alone right there, underlies the whole reason by which experts > have been infatuated with digital fonts for ages. hinting ... well, rendering is not part of the frontend .. tex is shape agnostic and whether or not hints get passes is upto a backend and using them is up to a viewer or printer in fact, one can argue that metafonts have some kind of hinting as they deal with snapping and rounding but nowadays hinting ... displays are pretty good so ... > But I guess what you wrote earlier aligns in more ways than one with > what omega end-goal was, whether unwanted or not, routing along to > an opentype tunnel vision perspective, while shrugging off other > simplistic formats such as afm/tfm by breaking down the glyphs into > smaller pieces Although I would see it differently, and perhaps > I'm wrong. And perhaps it wasn't practical either, but for some > folks it was worth the extra complexities to undertake at the time, > while for many wasn't. Regardless, converters to take you over to > the containers' formats and include the tables later on was likely > needed either way. So why bother, right? I suppose that tex can adapt to anything out there, because most of the time it only constructs stuff and then needs dimensions of what it made. (There have been plenty proposals or experiments i think but in the end it is usage that makes things work out. We have some font stuff in context that cna be used for advanced irmprovements but no one uses them because it depends on fonts that never showed up.) > But pfc was the correct method and not others :) and for the right > reasons. Still unclear to me in what sense. You have to prove it with examples or some reference that explains how it could work out (from user input to reliable rendering.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl ----------------------------------------------------------------- ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___________________________________________________________________________________