Re: Most complete (free) Chinese font?
Am 01.08.2010 um 13:03 schrieb Leonardo Boiko: And it’s the only font I know with U+2E19 PALM BRANCH ⸙ It is not. Andron has it. Regards, A. St.
Re: Most complete (free) Chinese font?
On 2 Aug 2010, at 08:52, Andreas Stötzner wrote: Am 01.08.2010 um 13:03 schrieb Leonardo Boiko: And it’s the only font I know with U+2E19 PALM BRANCH ⸙ It is not. Andron has it. As does Everson Mono. Michael Everson * http://www.evertype.com/
Re: Most complete (free) Chinese font?
Emphasis on “the only font _I know_”. I didn’t know Andron nor Everson Mono. Besides, while quality, both seem to be non-free, which is something I’m not interested in as a Debian user (nothing against it, it just isn’t my thing). On Mon, Aug 2, 2010 at 05:48, Michael Everson ever...@evertype.com wrote: On 2 Aug 2010, at 08:52, Andreas Stötzner wrote: Am 01.08.2010 um 13:03 schrieb Leonardo Boiko: And it’s the only font I know with U+2E19 PALM BRANCH ⸙ It is not. Andron has it. As does Everson Mono. Michael Everson * thttp://www.evertype.com/ -- Leonardo Boiko http://namakajiri.net
Re: Most complete (free) Chinese font?
On 2 Aug 2010, at 11:57, Leonardo Boiko wrote: Emphasis on “the only font _I know_”. I didn’t know Andron nor Everson Mono. Besides, while quality, both seem to be non-free, which is something I’m not interested in as a Debian user (nothing against it, it just isn’t my thing). Huh. Well, Leonardo, when I am independently wealthy, I'll be happy to give everything I do away for free. In the meantime, I find the the extremely occasional shareware fee I get to be a welcome affirmation that Everson Mono is appreciated. There is nothing shameful, or a shame, about non-free fonts. Michael Everson * http://www.evertype.com/
Re: Most complete (free) Chinese font?
When did I say there was something shameful about non-freeness? I only said, and I quote, that it’s not my thing. Since I run a free operating sytem, it can automatically download and manage free content, so it’s more convenient for _me_ to keep using free content. I manage about a thousand computers in a public university in Brazil, with little funding and plenty of bureaucracy. Dealing with custom licensing terms and ad-hoc downloading and manual installation is simply too inconvenient. It’s much simpler, for me, to stick to an automated system that guarantees freedom. As an author, you’re entitled to license your work to your heart’s content. Don’t take this as an accusation. As a sysadmin, I’m also entitled to not care about non-free stuff. I don’t think it’s shameful, I simply don’t use it. On Mon, Aug 2, 2010 at 08:11, Michael Everson ever...@evertype.com wrote: On 2 Aug 2010, at 11:57, Leonardo Boiko wrote: Emphasis on “the only font _I know_”. I didn’t know Andron nor Everson Mono. Besides, while quality, both seem to be non-free, which is something I’m not interested in as a Debian user (nothing against it, it just isn’t my thing). Huh. Well, Leonardo, when I am independently wealthy, I'll be happy to give everything I do away for free. In the meantime, I find the the extremely occasional shareware fee I get to be a welcome affirmation that Everson Mono is appreciated. There is nothing shameful, or a shame, about non-free fonts. Michael Everson * http://www.evertype.com/ -- Leonardo Boiko http://namakajiri.net
Free font with medievalist characters (was Re: Most complete (free) Chinese font?)
Le dimanche 01 août 2010 à 08:03 -0300, Leonardo Boiko a écrit : Oh, it _is_ totally blocky, and will look terrible if scaled to anything other than its natural 16-pixel size. My point is, this is how it’s supposed to be, cause it’s a bitmapped, monospace terminal font. Like Terminus or xorg’s “fixed”; you use it for computer code, not books. And it’s the only font I know with U+2E19 PALM BRANCH ⸙ ;) Junicode (http://en.wikipedia.org/wiki/Junicode ) contains it, and its free (GPL licensed). This character comes from MUFI, so it's not surprising that Junicode has it. Andron (mensioned before) and Palenomas MUFI also should have it, and thei're free of charge (but not free for Debian). They should not pose administrative problems for you... Frédéric
Re: Most complete (free) Chinese font?
On 2 Aug 2010, at 13:10, Leonardo Boiko wrote: When did I say there was something shameful about non-freeness? I only said, and I quote, that it’s not my thing. I find the term non-free to smack of élitism and a view that commerce is undesirable. And I'm not even very good at being a merchant. It’s much simpler, for me, to stick to an automated system that guarantees freedom. Indeed? Let us weep for those benighted folks who shackled themselves to the world of pecuniary transaction by choosing to render a shareware fee for Everson Mono Heh. Michael Everson * http://www.evertype.com/
RE: Most complete (free) Chinese font?
You might try looking at http://www.alanwood.net/unicode/fonts_windows.html TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Re: CSUR Tonal
I've copied an updated draft proposal to: http://luke.dashjr.org/tmp/chores/tonal.html I believe I have addressed all of the suggestions raised to my earlier draft. Please let me know what you all think. Thanks, Luke
RE: CSUR Tonal
Luke-Jr luke at dashjr dot org wrote: I've copied an updated draft proposal to: http://luke.dashjr.org/tmp/chores/tonal.html I believe I have addressed all of the suggestions raised to my earlier draft. Please let me know what you all think. If it were up to me, which it is not, I would consider this proposal suitable for posting on the CSUR site. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
Re: Indian new rupee sign
Hey everybody, I wasn't serious about the Ryerson logo. My point was that those of us who are not IPR lawyers shouldn't pretend to be IPR lawyers. The UTC and WG2 and Indian government can figure out for themselves what legal obstacles, if any, need to be overcome before the rupee sign can be encoded. That's all. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
Re: UTS#10 (UCA) 7.1.3 Implicit Weights, Unassigned and Other Code Points
Philippe Verdy said: Implicit weights for unassigned code points and other characters that are NOT ill-formed are suboptimal, as noted in the proposed update. To follow up on Mark's response on this thread... It should take into account their existing default properties, notably : [ long list snipped: includes surrogates, noncharacters, and unassigned characters in various ranges ] Currently, if the Unicode scalar value (or invalid code unit) is (unsigned 32-bit value), then they are treated as expansions to ignorable collation elements: [....] That statement is incorrect. The UCA currently specifies that ill-formed code unit sequences and *noncharacters* are mapped to [....], but unassigned code points are not. If we want to be smarter, we should not treat ALL the cases above as fully ignorable at the first three levels, and should get primary weights notably: Hmmm, if we want to be smarter, we should read what the actual specification says. 5. Unassigned code points that are in allocated blocks for non-Sinographs, non-Special, and with default RTL directionality (in the BMP or SMP). 6. Unassigned code points that are in allocated blocks for non-Sinographs, non-Special, and with default RTL directionality (in the BMP or SMP). When they will be allocated, most of them will NOT be fully ignorable, and its probably best to give them appropriate implicit primary weights They already are, but... so that they with primary weights lower than than those used for characters in the same block, but still higher that encoded characters from other blocks have that lower primary weights than assigned characters in the block. Gaps should be provided in the DUCET at the begining of ranges for these blocks so that they can all fit in them. The benefit being also that other blocks after them will keep their collation elements stable and won't be affected by the new allocations in one block. That particular way of assigning implicit weights for unassigned characters would be a complete mess to implement for the default table. A. It would substantially increase the size of the default table for *all* users, because it would assign primary weights for all unassigned code points inside blocks -- code points which now simply get implicit weights assigned by rule. B. The assumptions about better default behavior are erroneous, because they presuppose things which are not necessarily true. In particular, the main goal appears to be to assure well-behavedness for future additions on a per-script basis, since primary weight orders are relevant to scripts. However, several of the most important scripts are now, for historical reasons, encoded in multiple blocks. A rule which assigns default primary weights on a per block basis for unassigned characters would serve no valid purpose in such cases. C. In addition to randomizing primary weight assignments for scripts in the case of multiple-block scripts, such a rule would also introduce *more* unpredictability in cases of the punctuation and symbols which are scattered around among many, many blocks, as well. In general this proposal fails to understand that the default weights for DUCET (as expressed in allkeys.txt) has absolutely nothing whatsover to do with block identities or block ranges in the standard. The weighting algorithm knows absolutely nothing about block values. The other categories above (for code units exceeding the range of valid scalar values if they are not treated as errors, or for code points with valid scalar values and assigned to non-characters if they are not treated as errors, or for code points with valid scalar values assigned or reserved in the special supplementary plane) can be kept as fully ignorable, using null weights on the (fully ignorable) first three levels, and the implicit (last level) weights for scalar value or code unit binary weights. Except that such treatment is not optimal for the noncharacters. As noted in the review note in the proposed update for UTS #10, noncharacters should probably be given implicit weights, rather than being treated as ignorables by default. That is a proposed change to the specification. Note that valid PUAs are not concerned here: they have not in the DUCET, even if they are subject to possible private tailorings to make them fully ignorable or use any other weights (including with contractions or expansions). Without such known private convention, they should still be treated as fully ignorable (using the implivit weights for the last level sorting by scalar values). No, they should not. But the UCA algorithm completely forgets to speak about them, so it treats them with BASE=0xFBC0, giving non-zero primary weights and making them sort after all Sinographs and before 'Trailing weights'... Correct. But is by design -- not because the algorithm completely forgets to speak about them.
Draft Proposal to add Variation Sequences for Latin and Cyrillic letters
I have compiled a draft proposal: Proposal to add Variation Sequences for Latin and Cyrillic letters The draft can be downloaded at: http://www.pentzlin.com/Variation-Sequences-Latin-Cyrillic2.pdf (4.3 MB). The final proposal is intended to be submitted for the next UTC starting next Monday (August 9). Any comments are welcome. - Karl Pentzlin
Re: Draft Proposal to add Variation Sequences for Latin and Cyrillic letters
0073 FE00/FE01 - must be LATIN SMALL LETTER S, not LETTER B. Leo On Mon, Aug 2, 2010 at 5:04 PM, Karl Pentzlin karl-pentz...@acssoft.de wrote: I have compiled a draft proposal: Proposal to add Variation Sequences for Latin and Cyrillic letters The draft can be downloaded at: http://www.pentzlin.com/Variation-Sequences-Latin-Cyrillic2.pdf (4.3 MB). The final proposal is intended to be submitted for the next UTC starting next Monday (August 9). Any comments are welcome. - Karl Pentzlin
Re: Draft Proposal to add Variation Sequences for Latin and Cyrillic letters
On Mon, Aug 2, 2010 at 8:04 PM, Karl Pentzlin karl-pentz...@acssoft.de wrote: I have compiled a draft proposal: Proposal to add Variation Sequences for Latin and Cyrillic letters The draft can be downloaded at: http://www.pentzlin.com/Variation-Sequences-Latin-Cyrillic2.pdf (4.3 MB). The final proposal is intended to be submitted for the next UTC starting next Monday (August 9). Two things jumped out at me on a quick glance. First, I don't see why unspecific forms should be encoded; if you want a nonspecific a, 0061 is the character. Secondly, Fraktur and Antiqua are different writing systems with slightly different orthographies; instead of messing around with variation sequences, just accept that. If they must be distinguished, surely the long-s variation sequence could be used in non-Fraktur fonts, like Blackletter and 18th century-style fonts. -- Kie ekzistas vivo, ekzistas espero.
Re: Most complete (free) Chinese font?
Hello Michael, I hope you still remember that I am one of the (apparently very few) people who paid for Everson Mono. That was more than ten years ago. On 2010/08/03 1:02, Michael Everson wrote: On 2 Aug 2010, at 13:10, Leonardo Boiko wrote: When did I say there was something shameful about non-freeness? I only said, and I quote, that it’s not my thing. I find the term non-free to smack of élitism and a view that commerce is undesirable. And I'm not even very good at being a merchant. Instead of criticising a term, would you mind proposing a different term? It’s much simpler, for me, to stick to an automated system that guarantees freedom. Indeed? Let us weep for those benighted folks who shackled themselves to the world of pecuniary transaction by choosing to render a shareware fee for Everson Mono Nobody has to weep for me. I actually haven't used Everson Mono much, I'm not even sure whether I ever used it, but at the time I found the idea that somebody was working on a font that covered Unicode really worthy of support. Regards,Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
Re: Indian new rupee sign
Doug Ewell said on Mon, Aug 02, 2010 at 03:34:18PM -0700,: My point was that those of us who are not IPR lawyers shouldn't pretend to be IPR lawyers. The UTC and WG2 and Indian government can figure out for themselves what legal obstacles, if any, need to be overcome before the rupee sign can be encoded. That's all. +1, and a claim of IPR of any kind, and unhindered use are incompatible. -- Mahesh T. Pai
