Note that there are two measurement systems involved: first the camera, and then the human eyes. Your reasoning could be correct if there were only one: "the sensor is most sensitive to green light, so less sensor area is needed".
But it is not the case, we are first measuring with cameras, and then presenting the image to human eyes. Being more sensitive to a colour means that the same measurement error will lead to more observable artifacts. So to maximize visual authenticity, the best we can do is to make our cameras as sensitive to green light (relatively) as human eyes.
Oh you are right! I’m so dumb! Of course it is the camera. To have the camera have the same sensitivity, we need more green pixels! I had my neurons off.
Thanks.
An example: the text "Hello There إلا بسم الله Beep Boop!!" should turn into two visual lines as follows if it is line-wrapped:
Hello There إلا
بسم الله Beep Boop!!
Notice how "إلا" goes from the fifth word (from left to right) to the third after the line wrap. This won't work if shaping happens before line wrapping.
Nitpicking your nitpicking: I think the author meant better.
The "ae" example was used as an introductory example for us English readers.
Unlike the Arabic examples where ligatures are mandatory and supported by most
Arabic fonts, not many English fonts have an "ae" ligature these days. Not to
mention this is a web page and a user can freely apply their !important font
styles.
Using æ to mean "treat it as an 'ae' rendered by ligature which is
visually indistinguishable" does not mean the author knows nothing about this
(although the wording can use some improvement to reduce the ambiguity).
I don't understand: æ is not a ligature so it's not an example of a ligature. There are English ligatures to use.
Also, most fonts have many characters beyond ASCII, including æ. If your font lacked it then you would see an empty box, not the two letters ae. Applying a font style would not change the rendering of æ into ASCII letters; I don't think it changes the rendering of English ligatures, which are separate code points in Unicode.
I saw that headerless cons patch too! [1] It's quite exciting to see what a customizable GC is able to do, and I agree a GC with targeted object types (combined with tagged pointers) have quite some room for optimization compared to generic GCs in JVM.
Your cursory search likely provided outdated info. [0] Quoting from it's maintainer: [1]
Waterfox is independent again: [0]
And System1 are an “ad-tech” company but the term should be used loosely. The ownership made sense as they are a search engine aggregator and they own a bunch of old school search engines like DogPile, InfoSpace etc. Nothing to do with what people associate ad-tech with, i.e. tracking you across the web or collecting personal data.
The WeTab / Infinity team has responded to this [1] (in Chinese). Basically, they argue that:
- The Clean Master extension has long been sold, and the malicious updated was not pushed by them.
- The other two mentioned extensions are not at all malicious. They collect use info for extension opt-out-able features and analytics (using Google Analytics and Baidu Analytics).
- They are communicating with the extension stores to restore their extension.
Let's hope it's not an AI company making AI-generated accusations.
The first point isn't meaningful from a user's perspective.
There's no difference between me trusting you and you pushing malware to me vs you selling your deploy access to a third party and the third party pushing malware to me.
Especially if selling the extension doesn't remove the old one from the browser automatically and reset it's rating to 0, download count to 0 and remove all the comments/reviews.
I think in the chrome extension store you can't even change the email account attached to the extension. The only correct way to transfer an extension seems to be deleting it and having the new party create a new one.
Statements like this always feel a bit rude to me—as a Chinese, I use em dashes (in Chinese texts) on a daily basis and insert them in English texts when I see fit.
A bit of background: Em dashes “—” (or, very often, double em-dashes “——”) are to Chinese texts what hyphens “-” are to English texts. We use them in ranges “魯迅（1881－1936）”, in name concatenations “任－洛二氏溶液（Ringer-Locke solution）”, to express sounds “呜——”火车开动了, or `“Chouuuuuuuuu”, starts the train' in English, and in place of sentence breaks like this——just like em dashes in English texts. They are so commonly used that most Chinese input methods map Shift+- (i.e., underscores “_”) to double em-dashes. So, as a result, while I see many English people have to resort to weird sequences like “Alt + 0151” for an em-dash, a huge population in the world actually has no difficulty in using em-dashes. What a surprise!
As for this article, obviously it was translated from its Chinese version, so, yeah I don't see em-dashes as an AI indicator. And for the weird emoji “” (U+1F54A), I'm fairly certain that it comes from the Chinese idiom “放鸽子” (stand someone up, or, literally, release doves/pigeons), which has evolved into “鸽了” (pigeon'ed), a humorous way to say “delayed, sorry!”.
Totally agree, I don't think em dashes are a particularly useful AI tell unless they're used in a weird way. Left to my own devices (as a native English speaker who likes em dashes and parentheticals), I often end up with at least one em dash every other paragraph, if not more frequently.
On another note, it may be useful to you to know that in most English dialects, referring to a person solely by their nationality (e.g., when you wrote "as a Chinese") is considered rude or uncouth, and it may mark your speech/writing as non-native. It is generally preferable to use nationalities as adjective rather than nouns (e.g., "as a Chinese person"). The two main exceptions are when employing metonymy, such as when referring to a nation's government colloquially (e.g., "the Chinese will attend the upcoming UN summit") or when using the nationality to indicate broad trends among the population of the nation (e.g., "the Chinese sure know how to cook!"). I hope this is considered a helpful interjection rather than an unwelcome one, but if not, I apologize!
Thank you! It would indeed require extra effort for me to notice issues like this, and it is very nice of you to have pointed it out!
Speaking of personal devices, I also have a dedicated key binding for en dashes “–” (because, well, I already have a whole tap layer for APL symbols, and it costs nothing to add one more). Since we're on HN, I believe many people here can easily do that if they wish to, so I too don't think en/em dashes are very telling, especially on HN.
But it is not the case, we are first measuring with cameras, and then presenting the image to human eyes. Being more sensitive to a colour means that the same measurement error will lead to more observable artifacts. So to maximize visual authenticity, the best we can do is to make our cameras as sensitive to green light (relatively) as human eyes.
reply