glitch

See https://news.ycombinator.com/item?id=22206663 for discussion.

(1) I acknowledge that the author already states that "[they are] quite well aware that this uses Unicode not ASCII."

(2) Having said that, as a request to everybody for future text-based creations, could we please stop referring to non-ASCII text as "ASCII". Using characters that aren't in ASCII really shouldn't be referred to as ASCII. Pretty please.

(3) The more generic label of "text QR" or "text-based QR" would be better, in my opinion. In this particular situation, saying "Unicode text QR" or "Unicode QR" would also be appropriate.

Note well: "tobacco use" is a umbrella term that includes e-cigarette use (with nicotine), since the nicotine in vape juice is derived from tobacco plants. Also note: "combustible tobacco product use" declined.

"Among high school students, during 2011–2018, no significant trend in the reported use of any tobacco product overall was observed (Figure 2). However, changes were observed for individual tobacco products over this period. A significant nonlinear increase in current e-cigarette use occurred from 2011 (1.5%) to 2018 (20.8%). During 2011–2018, significant linear declines in combustible tobacco product use (from 21.8% to 13.9%) and ≥2 tobacco product use (from 12.0% to 11.3%) occurred; by product type, significant linear declines occurred for cigars (from 11.6% to 7.6%), smokeless tobacco (from 7.9% to 5.9%), and pipe tobacco (from 4.0% to 1.1%). A significant nonlinear decline was observed for cigarettes (from 15.8% to 8.1%). A significant nonlinear change during 2011–2018 was observed for hookahs (from 4.1% to 4.1%).

Among middle school students, no significant change in use of any tobacco product overall occurred during 2011–2018 (Figure 3). However, changes for individual tobacco products were observed. A significant nonlinear increase in e-cigarette use occurred (from 0.6% to 4.9%) during 2011–2018. A significant linear decline was observed for combustible tobacco product use (from 6.4% to 3.3%), ≥2 tobacco products use (from 3.8% to 2.4%), cigarettes (from 4.3% to 1.8%), cigars (from 3.5% to 1.6%), smokeless tobacco (from 2.7% to 1.8%), and pipe tobacco (from 2.2% to 0.3%); a significant nonlinear change occurred for hookah smoking (from 1.0% to 1.2%)."

— https://www.cdc.gov/mmwr/volumes/68/wr/mm6806e1.htm

Note: 090310.pdf (9 March 2010) is an older version of the textbook. The latest revision of the textbook PDF (091117.pdf, 9 November 2017) is available at:

→ http://web4.cs.ucl.ac.uk/staff/D.Barber/textbook/091117.pdf

Aside:

⸰ Textbook homepage: http://web4.cs.ucl.ac.uk/staff/D.Barber/pmwiki/pmwiki.php?n=...

⸰ Online version homepage (should always contain link to latest revision): http://web4.cs.ucl.ac.uk/staff/D.Barber/pmwiki/pmwiki.php?n=...

⸰ Directory sorted by date: http://web4.cs.ucl.ac.uk/staff/D.Barber/textbook/?C=M;O=D

To add to this: "Why CUDA 'Cores' Aren't Actually Cores, ft. David Kanter" (Gamers Nexus, 2018 April 18, 18 min.) https://youtu.be/x-N6pjBbyY0

(I have not tried either of these solutions, so I'm not sure if they actually work.) Although still separate applications, Karabiner and Scroll Reverser are both free. (I mention this since you stated having to "pay for an app".)

(1) Karabiner: https://pqrs.org/osx/karabiner/ → Cf. Kellen Mace, "Separate Trackpad & Mouse Natural Scrolling in Mac OS X" (2014) https://kellenmace.com/automate-trackpad-mouse-natural-scrol...

(2) Scroll Reverser: http://pilotmoon.com/scrollreverser/

Curious: (1) Do you have some screenshots demonstrating this issue and (2) perhaps an example PDF that others could download for the purpose of issue reproduction? (I have not seen this issue, nor am I able to reproduce this issue after repeatedly trying under Preview. I have compared it with on-screen rendering under Acrobat XI, as well.) // Preview 10.0 (944.5), macOS 10.13.4 (17E202), MacBook Pro (13-inch, 2017)

For anyone that wants to download the books, I strongly recommend downloading the PDF archive on Archive.org because the image scans within the PDFs are of much higher quality. https://archive.org/details/Harvard-Classics

Here's an older version dated September 15, 2016 (which is 1 year, 5 months ago):

https://www.ssc.wisc.edu/~nwilliam/Econ702_files/abch.pdf

Sprite_tm’s presentation at the 2017 Hackaday Superconference... “Small Fruit: Disembiggening the Macintosh Plus” (31 min.) → https://youtu.be/V-PiNVPp5h0

It is a grave accent. Something which was and still largely is of little use to many that grew up in United States knowing only English. So, such users abused and re-purposed it as a "backtick", which feels like an unfortunate decay due to ignorance. But such things continually happen.

In all reality, it was originally named after Shockwave Flash, but the extension meaning was retcon'd to Small Web Format to avoid confusion with Shockwave.

It's marketing. Blatant ad. System76 had build quality issues in the past; no idea if they've fixed their issues in the present.

The trick is to use a font that has ligatures, but not to use the ligature characters directly. Let the presentation choose the glyphs to display, and let the encoded characters remain separate as they should. CSS handles this with "font-variant-ligatures" (works in some browsers). I just did a test in Chrome on OS X; toggling between "font-variant-ligatures: common-ligatures" and "font-variant-ligatures: none" changed the presentation, but it did not negatively impact the accessibility, searchability, etc. as the ligature characters would. Automatic glyph substitution in presentation yay; encoded character substitution nay.

Ah! That explains the cruft I've seen today with the mess of truncated tweets with links to themselves (twitter.com/i/web/status/…) at the end of the tweet text. (If you use a third-party client, you'll see this duct-tape in the tweets.)

Also check out https://www.w3.org/History/1991-WWW-NeXT/Implementation/

Went to a dark room with an Apple Remote; let my eyes adjust for a little while. Pressed it many times; I couldn't see the infrared coming from the LED with my naked eye. (But the camera on my iPhone imaged the infrared from the remote's LED.) I envy your biological wavelength detection.

I don't know about Apple, but I know lots of companies that will avoid using the registered logos of others whenever possible, as it opens up the possibility for being bound by another legal string. By avoiding the issue entirely -- not even using the registered logo -- this completely avoids the question of fair-use vs. being sued and/or paying fees.

Now, what they will do is explicitly write the company that has the registered logo -- requesting written approval for a particular context/usage. If they get that, then they will use the registered logo. But as the default case, "avoid as much as possible" is standard policy. Some are more afraid of legal matters than others. Whether this fear is justified is not as immediately relevant in this particular context, as is the existence of the fear itself and the consequences thus.

Cf. https://www.microsoft.com/en-us/legal/intellectualproperty/t...

"Poking fun" would be something along the lines of using the blue-screen-of-death screen as seen with previous networked computer icons in OS X. Whereas, in this instance, the visual representation is a very simple, generic "window" that is still distinctly different from any previously registered Microsoft Windows logos. To me, this instance appears to just be simply avoiding unnecessary use of a registered logo.

I could also get into it further, elaborating why textual registered trademarks may be considered easier to use for fair-use (used for informational purposes) versus registered graphical elements (i.e., logos), but I have no such desire.

This article is merely clickbait.

Bay Area FreeBSD User Group (BAFUG) August 2015 meeting. There's a video recording available at http://www.nextbsd.org/jordan-hubbard-visits-bafug/

CR3: https://en.wikipedia.org/wiki/Control_register#CR3

Some relevant excerpts from Mac OS X and iOS Internals: To the Apple's Core by Jonathan Levi:

From page 133: In 64-bit mode, there is such a huge amount of memory available anyway that it makes sense to follow the model used in other operating systems, namely to map the kernel’s address space into each and every process. This is a departure from the traditional OS X model, which had the kernel in its own address space, but it makes for much faster user/kernel transition (by sharing CR3, the control register containing the page tables).

From page 266: Still, unlike Windows or Linux, OS X applications in 32-bit (Intel) used to enjoy a largely unfettered address space with virtually no kernel reservation — that is, the kernel had its own address space. Apple has conformed, however, and in 64-bit mode OS X behaves more like its monolithic peers: the kernel/user address spaces are shared, unless otherwise stated (by setting the -no-shared-cr3 boot argument on Intel architectures). The same holds true in iOS, wherein XNU currently reserves the top 2 GB of the 4 GB address space (prior to iOS version 4 the separation was 3 GB user/1 GB kernel).

He wrote "often", not "always".

It's obvious from the context. Adding "vertical" is unnecessary. This is conversational writing, not legal nor instructional writing.

Yeah, I noticed that too. I told them and they fixed that typo.

Digging deeper under the Forums, some random tid-bits...

• Releases: http://www.apollo-core.com/knowledge.php?b=6

   ◦ FPGA image: http://www.apollo-core.com/bringup/apollo_mini_2000_83.jic

   ◦ phoenixinit: http://www.apollo-core.com/bringup/phoenixinit

• Some photos: http://www.apollo-core.com/bringup/

• Altera FPGA, etc. http://www.apollo-core.com/knowledge.php?b=3&note=3120

This can already be done. This doesn't make things any "worse" than they already are in that regard.

Cf. http://www.guanotronic.com/~serge/papers/fc15-fonts.pdf & http://pet-portal.eu/files/articles/2011/fingerprinting/cros...

Also, to more appropriately answer your question, there exists a notion for separating "document" and "UI widget" fonts. Documents often have content to be read at long lengths. UI widgets don't have the "long length" constraint in their design context. As one example, the system font may be lighter in weight to achieve an elegant looking aesthetic. However, while the lighter weight font is acceptable for the UI widgets, it isn't nearly as acceptable for readability of document text. It's a nice to be able to have that design/usability context distinction. The default context for the web is that of the document, not the UI, the default CSS sans serif font should be the "document font".

In the context of general "-system-✻" font & style identifiers (not merely -apple-system-✻ specific)...

1. Knowing extremes and layout boundary conditions: You can reasonably test extremes of wide and condensed font metrics; it's not that hard.

2. Rigid designs: If you don't want to use the ambiguous system font, you don't have to; it doesn't change that. If you have a design that requires certain rigidity and inflexibility, you can have your explicitly imported web fonts and be happy.

3. Flexible designs: Be flexible and fluid. Be like water. Heck, there are slight unknowns with using any non-explicitly defined font. Using CSS generic-family identifiers (serif, sans-serif, cursive, fantasy, and monospace) have variation and are not guarantees, but you can still use them without much concern for layouts that are designed to be appropriately accommodating.

4. Native look and feel: If you want to achieve something closer to the native system look and feel, being able to use the system font from CSS helps you out immensely. For those that (1) design their layout to flow relatively nicely without being overly fixed or constrained and (2) want to have an appearance matching the system font, then it's great!

5. Testing: From my experience, this doesn't pose any significant testing issues. Besides testing artificial extremes of wide and condensed font metrics, practical testing across multiple environments isn't anything new. It's something that already gets done by any skilled front-end designer. Many shops will test across many browsers under may platforms anyway. Sites like http://browsershots.org, https://www.browserstack.com/screenshots, http://www.crossbrowsertool.com, http://www.browsershots.atm, https://www.browserling.com, http://dev.modern.ie/tools/screenshots/ and many others are out there for people who don't have or don't want to deal with the setup in-house to do testing. (You might have to supplement it with mobile devices in-house, sure.) You can easily cover 95% of the actually used environments (browsers/platforms) very explicitly, and for the environments you don't explicitly test for, at that point of successful testing, it's very likely there won't be an issue, and if there is an issue, it should be minor and not significantly matter. Be pragmatic.

Thinking beyond just OS X, the purpose for a general "-system-*" font and style identifier would be that web apps could more easily have the "native look" without having to explicitly identify the operating environment. (And identifying the operating environment still doesn't necessarily tell you what their system font is set to; that's still heavily presumptuous.)

Maybe someone's Linux distro is using a serif typeface, or a monospaced serif typeface, or a monospaced sans-serif typeface, or something more like Comic Sans (have seen this more than once) as their system font.

The point is, we can do better than what we have now with regard to the goal of making web applications approach the "native look and feel" more easily and more simply. It's a balance game; a balance between adding features like this (every feature adds a little bloat) that also potentially help eliminate bloat elsewhere in code (e.g., javascript to fingerprint the environment). Further, getting the system font is something that CSS should be able to know about without the aid of JavaScript; there are lots of simple forms and data entry "applications" that don't use any JavaScript (nor should they) and would benefit from a better presentation. Writing a native application for any platform, I want to get the system font, and not have to know or assume any qualities of what that font is. With typical native applications, the default font is intrinsic in the UI widgets your using, so you don't have to think about it. With the web, typically the default font is a "document font" and not the UI widget font, so you need to be able to have some sort of mechanism beyond the default font in order to get the system UI font.