Bluetooth 5 will quadruple the range, double the speed - <AUTHOR> https://www.engadget.com/2016/06/16/bluetooth-5/ <comment><USER2> I could not care less.

\- 1.0 to 1.2: Hard to pair, and very unreliable. First major version, I'm sure they'll fix it...

\- 2.0: More bandwidth. Still hard to pair, still unreliable.

\- 2.1: Adds "Simple Secure Pairing". Still hard to actually pair. Still unreliable.

\- 3.0: More bandwidth. More features. Still hard to pair, still unreliable.

\- 4.0: Bluetooth Low Energy released. Still hard to pair, still unreliable.

\- 4.1: More features. Still hard to pair, still unreliable.

\- 4.2: More features. Still hard to pair, still unreliable.

\- 5.0: More range, more bandwidth. Still hard to pair, still unreliable.

I have the latest Apple "Magic" Trackpad, hooked up to a Mac Pro. At least once a day, latency will take a dive, or it will completely disconnect. I have to turn the trackpad on and off repeatedly, to see if it will finally re-pair by itself. No other recourse, you can't easily access bluetooth settings on a mac with only a keyboard. (Which I made sure to get with a USB plug, since my last bluetooth keyboard had the same issues.)

I also have a Samsung Level BT headset, paired with a Samsung Note 5 phone. I can listen to Google Music or Player.fm for between 1 and 10 minutes until the headset will suddenly blast noise at full volume, and become unresponsive until I turn it off and back on again. Left my ears ringing on more than one occasion.

I've replaced my "magic" keyboard with a USB one, and recently hooked the trackpad back up via USB. I've stopped using the Samsung Level and went back to an old pair of headphones with a 3.5mm plug (that Apple is now trying to get rid of.)

I had a past without wires. I am moving to a future with them.

<comment><USER3> I used the Bluetooth Audio in my new car for about two weeks.

It was actually pretty reliable, and felt like the future. I'd get in, turn the car on, my phone would pair itself and pick up where it left off, and I never once had to take it or my keys out of my pocket. Then I started to actually _listen_ to my music.

The audio over bluetooth was frequently out of tune. I'm a musician, so I can definitely hear this and it's infuriating. VLC on Windows had the same problem for years and everyone told me I was crazy, but the car was at least twice as bad. It sounded like an old cassette player, if anyone remembers those. Googling reveals this to be a common issue with many different varieties of bluetooth speaker. I can only imagine it's doing some sort of time stretching to "hide" latency in the packets but, well, it's not hiding it well enough for my ears. Trying to listen to anything melodic, especially piano pieces, was just awful.

Fortunately, I discovered that my car also has a shockingly _excellent_ USB Audio implementation, so I copied the Music from my phone onto a large USB drive and have been happy ever since. More wires for me please, the future isn't ready.

<comment><USER4> Your phone may already be able to do it on its own: get an OTG adapter for your phone (usually MicroUSB male to USB A female) and plug a USB cable in and use your phone directly.

<comment><USER3> Alas, my phone is running a newer version of Android, and does the Media Protocol thing instead of doing Mass Storage. I usually don't expect to be able to access its files in a sane manner over USB; it's hit or miss.

Instead, I use Syncthing, so my files are synced properly between the phone and my computer using my wireless network, no cables needed. I just copy the same folder to my USB drive periodically and don't need to mess with it beyond that. (In a pinch, I suppose I could use the OTG cable to update the USB drive using my phone.) I like being able to have the drive plugged into the car at all times, as it's one less thing to fiddle with when getting in and out.

If I'm going to plug a wire into my phone for my car, I'd _much_ rather just use the standard AUX (3.5mm headphone jack) port that's built in, as it's simpler and more reliable. I still do this from time to time if I feel like using Youtube, Google Play, or another streaming based service, or if I need to hear something on my phone (like Navigation).

</comment></comment></comment></comment><comment><USER5> That's nice, but the biggest UX problem with Bluetooth is still the pairing misery. It's 2016 and it's still nearly impossible to use any one Bluetooth device with multiple other devices. Try switching a Bluetooth headset from an iPhone to a Mac or convincing your car to switch from one phone to another.

It's a huge mess and its not just a matter of the technology not working as designed. These are fundamental problems that nobody seems to worry too much about, apart from a small number of vendors (Apple did a decent job solving the pairing problem with the Apple TV: [http://9to5mac.com/2013/07/29/new- apple-tv-os-offers-nfc-lik...](http://9to5mac.com/2013/07/29/new-apple-tv-os- offers-nfc-like-bluetooth-ios-remote-setup/)).

I realise it's pretty hard to beat the intuitive action of plugging physical cables into devices to connect two things, but if we really want to get rid of cables, things need to be easier.

<comment><USER6> Apple's stylus has a pretty effective and reliable pairing method: just briefly plug it into the tablet.

Too bad this method can't be more generally used.

<comment><USER7> You get pretty much the same thing these days if both devices support NFC. Just get within range, and ding.

<comment><USER8> Standardise that and make it ubiquitous and then it's interesting. Apple has the advantage that they own their entire platform so they can adopt a new "standard" immediately.

<comment><USER7> The standard already exist, and has been with us since 2.1. Now the ubiquity thing is quite another kettle of fish...

<comment><USER8> I didn't know that, cool! Though also depressing...

</comment></comment></comment></comment></comment></comment><comment><USER9> I don't need more range or more speed. I need it to reliably connect and stay connected while devices are well within range of each other, and stop breaking every time I upgrade anything. Unfortunately that would require making it less complex, which is about as likely as a broken egg spontaneously reassembling.

<comment><USER10> As a matter of fact "more range" is quite the opposite of what I want from Bluetooth. Do I really need to have 5000 keyboards within range of my computer at the office, instead of the 100 I already have? I definitely do not.

<comment><USER11> Headphones are the big benefactor here, for me at least. I can walk to the kitchen with my wireless headphones.

<comment><USER12> Agree, I look forward to the day I can leave my iPhone in a gym locker and work out with just headphones

<comment> TD-Linux I'd highly recommend getting a tiny mp3 player (say Clip Zip, though they are now discontinued...) and a short light headphone cable. Why send audio wirelessly when the tech to play it is as small as the receiver?

There are also headphones with built in players, I don't know how the quality of those is though.

<comment><USER13> Pretty much all the decent dedicated MP3 players have been discontinued. The last really great one for me was the Samsung's range (nee Yepp). But unfortunately the last one was the YP-U7 back in 2012 and it's very obvious they aren't going to make any more, even though they never announced it.

Sony still does players but they're not very good.

<comment><USER14> You can still get iPods in all sizes and colors. They're pretty decent.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> You know there's a problem when a majority of the comments (on a website filled with software engineers and other technologically inclined people) are all claiming that Bluetooth simply sucks in terms of usability. Imagine how hard it would be for someone like my parents to debug a Bluetooth pairing issue.

I think they need to focus 100% of their efforts on addressing some of these issues which seem to have been a problem since the beginning.

Bluetooth is "almost there" in my opinion. It's incredibly convenient (when it works), and I can envision how great it will be once they work all the kinks out. It has been getting better and I'm confident it will keep improving.

Let me just add another data point:

I have a 2013 Android phone and a 2011 car. Luckily, the car supports playing audio through Bluetooth which is really cool when it works. However, every time I get into the car, there's a 50/50 chance that BT audio will actually work. The phone always pairs with the car, but it seems like it doesn't reliably "negotiate" the audio capability. Sometimes I can make a phone call which seems to reset the system and can cause it to start working, but other times I have to actually power cycle the phone.

The other issue is that every once-in-a-while, there will be this spontaneous audible crackle. After the initial crackle occurs, there will be periodic crackles about once every 10 seconds from there on out. The only way to get it out of this state is to make a call or restart the phone. It seems almost like there's some kind of memory leak in a buffer or something which causes it to eventually run dry and bounce off of being empty.

These issues seem more software related and probably have nothing to do with the Bluetooth standard itself, but I won't let that stop me from ranting.

<comment><USER16> In my experience, if the implementation is wrong often enough that most people think the procotol/spec are to blame, than the protocol/spec are usually too complicated.

<comment><USER17> In my experience, no standard is too simple for someone to mess up implementing.

<comment><USER18> True, but in the case of BlueTooth, the standard is so complex that _everyone_ _does_ mess up implementing it.

</comment></comment></comment></comment><comment><USER19> Working with Bluetooth on a project last year was a gigantic pain in the ass.

Linux support was reasonably good, though with bizarre quirks and changes of tooling between libbluetooth versions. OSX was a total nightmare.

The project is currently stalled because three days before I had to head off (I was doing all of the programming and troubleshooting on the software side) my collaborators decided to inform me that they would be using a different laptop to what they'd been using for the rest of the project, and when we tried our software with that version of OSX and hardware, it refused to work nicely. We eventually came up with a bizarre pairing ritual that involved removing devices, then quickly adding them, and in a specific order, and then that mysteriously stopped working and now I don't have access to hardware to fix it.

Knowing what I now know, if I'd had my time again I would have recommended ESP8266 based boards instead of the LightBlue Beans we were using. Even though one of our requirements was low power usage (which we certainly got through Bluetooth 4), it probably would have been less hassle to just make the WiFi modem sleep for a period and then transmit in bursts.

<comment><USER20> Depending on how much data you need to transfer between the two devices, I'd highly recommend a pair of ZigBee radios for low-bandwidth (<250k), super-low- power applications. Specifically using a pair of XBee (series 1) radios in "transparent" mode, you get what looks like a serial device on either end. When used with a USB dongle, you can simply write your code to use basic ioctl ops on the USB device file, which works well across most POSIX platforms.

</comment></comment><comment><USER21> I think a lot of the comments here could be attributed to the terrible Bluetooth software stacks that are around (Car head-decks, Android (all versions), Windows 8-10 default stacks).

I've got a brand new Plugable BT4 dongle that barely works in Win 10 because Broadcom haven't updated their suite so it relies on the default 10 drivers - you can't have a HFP and A2DP service running at the same time so a headset with speakers and mic won't work.

<comment><USER22> At what number of terrible Bluetooth software stacks does one start wondering if there isn't something fundamentally wrong with the specification that makes it so incredibly hard to get right?

It's been bad from day one with Widcomm and later Bluesoleil on Windows. Mac OS X for years had a Bluetooth where after a couple of hours of using the DUN profile it would need a reboot, on an otherwise nicely reliable operating system. Mice on Bluetooth have never worked as smoothly, reliably, or as well as just using a proprietary protocol like Logitech Unifying.

It's not that I necessarily think it's an unsolvable problem, it's just that after a decade with so many multiple implementations that can't get it right I feel Bluetooth itself has to bear some responsibility.

<comment><USER23> bluetooth is an extended public alpha

I so can't wait for phones to drop 3.5mm jacks so playing music can become an infuriating ritual too

</comment></comment></comment><comment><USER24> Bluetooth is very easy to hate. It never ever just works: the pairing rituals, the flakiness. It's annoying.

But in recent years it has become more and more invisible. You've probably used Bluetooth in the past 12 months without noticing. Invisibility is something that the Bluetooth SIG should strive for.

<comment><USER25> I can think of one device where Bluetooth has been invisible, the Surface Pro 3 pen.

</comment></comment><comment><USER26> So much negativity about bluetooth in these comments ... and yet I can happily say that bluetooth has really changed my life. Bluetooth headphones allow me to walk around and exercise without an annoying cord trailing the length of my body. And I can get to the office and sit down with my mouse and keyboard and just start typing without plugging anything at all in. While it certainly had early problems, I'm super happy with it these days and especially the increase in bandwidth will be very welcome.

<comment><USER27> Bluetooth has made me feel happy about the existence of cords. Ahhhhhhh, I think to myself: it will definitely work, when I plug this thing into that other thing.

</comment></comment><comment><USER28> For those who have given up on Engadget (I can't be the only one):

[http://arstechnica.com/gadgets/2016/06/bluetooth-5-spec- comi...](http://arstechnica.com/gadgets/2016/06/bluetooth-5-spec-coming-next- week-with-2x-more-range-and-4x-better-speed/)

<comment><AUTHOR> What's wrong with Engadget?

<comment><USER29> It's 80% clickbaity bullshit and 20% mediocre gadget reviews. Long gone are the days when Engadget was a relevant source of tech journalism. On a tangentially related note, does anyone remember Engadget's apple-only sister site TUAW? That was a great outlet for a good long while until Engadget started to shit the bed a couple years ago.

</comment></comment></comment><comment><USER30> What I want from my wireless devices is not more range or speed, but _total_ freedom from wires, especially for charging.

I remember from an Intel demo from a while ago, where they showcased a number of peripherals using their inductive charging tech, where you can just dump them onto a large inductive charging pad along with your phone and tablet without having to fumble with plugging wires into each one. _That_ 's the killer feature for a wireless device, in my opinion.

</comment><comment><USER31> Here is a device I would pay for:

A USB dongle that somehow pairs to my Apple Keyboard and Touchpad and presents itself as a standard USB keyboard and mouse to the OS.

I could plug said device to my cinema display's USB hub. This way both me and my wife could use the same workstation by simply plugging in the computer.

</comment><comment><USER32> Maybe I'm living in the past and haven't been informed, but is Bluetooth still unsecure?

<comment><USER33> Bluetooth 4.0 and 4.1 had a broken key exchange that was vulnerable to both passive and active attacks [1]. This could be remedied by a custom in-band or out-of-band key exchange, but I think it was rare for device manufacturers to go to those lengths.

The key exchange vulnerability was addressed in Bluetooth 4.2, which implements ECDH and is at least theoretically secure. [2]

[1] [https://www.usenix.org/conference/woot13/workshop- program/pr...](https://www.usenix.org/conference/woot13/workshop- program/presentation/ryan)

[2] [http://blog.bluetooth.com/everything-you-always-wanted-to- kn...](http://blog.bluetooth.com/everything-you-always-wanted-to-know-about- bluetooth-security-in-bluetooth-4-2/)

<comment><USER34> Except... that pairing in Bluetooth 4.2 is _still_ broken. And they apparently even used an algorithm from Bluetooth 2 that was known to be broken.

[https://pomcor.com/2015/06/03/has-bluetooth-become- secure/](https://pomcor.com/2015/06/03/has-bluetooth-become-secure/)

Basically Passkey Entry is broken so eavesdroppers can trivially learn the PIN. You must use a dynamic PIN (not always possible).

Oh and if you're thinking you can implement your own pairing method that is actually secure, via the Out-of-Band method, think again! Neither Android nor iOS support it.

<comment><USER35> >Neither Android nor iOS support [pairing ... via the Out-of-Band method].

I'm not sure this is actually true (unless you're talking about bugs with individual manufacturers implementation on Android?). Both iOS and Android support SSP with OOB key exchange via NFC.

There are lots of products that have been available that use this for pairing/connecting, eg: [https://www.bose.com/en_us/support/article/pairing-a- device-...](https://www.bose.com/en_us/support/article/pairing-a-device-with- nfc-soundlink-ae-headphones-ii.html)

<comment><USER34> Android supports OOB via NFC, but only as a special case. You should just be able to call `createBondOutOfBand()` but the method is hidden:

[https://android.googlesource.com/platform/frameworks/base.gi...](https://android.googlesource.com/platform/frameworks/base.git/+/master/core/java/android/bluetooth/BluetoothDevice.java#888)

I'm pretty sure iOS doesn't support pairing via NFC.

[https://www.linkedin.com/pulse/nfc-speakers-from-apple- you-c...](https://www.linkedin.com/pulse/nfc-speakers-from-apple-you-cant-use- iphone-6-pair-jamie-conyngham)

[http://www.informationweek.com/mobile/mobile- business/iphone...](http://www.informationweek.com/mobile/mobile- business/iphone-6-nfc-radio-limited-functionality/d/d-id/1315778)

So, no, they don't support OOB (except in one limited case on Android).

</comment></comment></comment></comment></comment><comment><USER36> Try going from having bluetooth off on your phone to bluetooth being on in your car that has bluetooth capable device. It sucks. Every car I've been has trouble pairing if bluetooth wasn't on prior to me entering the car. For one car, I had to turn the engine off for it pair. WTF?

</comment><comment><USER37> Forgive my ignorance, but how come the range is affected by the protocol? Wouldn't it be the aerial?

<comment><USER38> There are many things in a protocol specification that can affect range. Allowed transmission power, specifiying that compliant receivers should have X dBm sensitivity, data bit rate, channel frequencies, modulation, etc.

</comment></comment><comment><USER39> Its really exciting to see that kind of capabilities and potential that bluetooth 5 brings to the table for IoT. However, what excited me even more is the capabilities put forward by bluetooth 5 to boost beacon adoption and location-based services. Given how Google's recent updates such as Google Nearby and Android Instant Apps are also ones with location-based services at its core, bluetooth 5 onces it's launched will definitely boost beacon adoption to a significant extent.

</comment><comment><USER40> I guess that is with the same power usage, as it would be disingenuous if that were different, but it would be nice to have that confirmed.

Also, I guess that, for many IoT devices, keeping range and speed the same while decreasing power usage significantly (although, as a third guess, I expect 'double the speed' means that devices can go to low power mode quicker, potentially halving power usage of the entire device) might be more useful.

</comment><comment><USER41> The only reason I like Bluetooth at all is because the alternative is a bunch of USB receivers plugged into my NUC.

But I have to admit that it seems to work pretty well on my iPhone while years ago on other phones I had a lot of disconnects. I have one of the LG around the neck headsets and it's actually really good at this point.

I'd like to see more BT headsets for PC hit the market. The only ones I could find were from Turtle Beach.

<comment><USER42> >. I have one of the LG around the neck headsets and it's actually really good at this point.

These are great but the real drawback that keeps me from going wireless is still the audio quality. Hopefully this upgrade will be the end of that.

<comment><USER41> I'm concerned about Apple possibly removing the 3.5mm jack. Removing the ability to use a headset + charge my phone at the same time is going to be a killer. I may switch back to Android if that happens.

I bought one of the very few 3.5mm cellphone headsets I could find (Voistek) for my wife and it works pretty well. We shouldn't be forced into choosing between wired up for charging or wired up for headset/headphones.

</comment></comment></comment><comment><USER43> And then bluetooth became wifi.

</comment><comment><USER44> My hope for the future of phone/car interfaces is that once you've paired a phone, the touch screen basically becomes a display for the phone... I have a brand new (less than a week old) car, and the UI feels sluggish, and looks very dated at this point. I'd rather my N6P managed the whole thing. Hopefully BT5 can allow that to happen.

</comment><comment><USER45> Wonder why it was not thought earlier? After BT we saw development in WiFi,GPS, RDID etc. Nobody thought that BT could help indoor for the shopping mall usecase present in the article.

Now they are planning for late 2016, means it will only be available in new phones from 2017

</comment><comment><USER46> Ah great, a new BT version once again, when even the LAST standard isn't properly supported (and especially documented!!!) in BlueZ. Not to mention Windows (which usually comes with a next-to-useless stack, and every other stack costs $$$) or OS X...

</comment><comment><USER47> Nearly every comment in this thread is about pairing issues. I can definitely agree with most that I don't care about range and speed as much as I do the usability of pairing with multiple devices.

</comment><comment><USER48> While I'm not a fan of Bluetooth for data transfer (pairing pains), this could be great for cheap indoor location services, eg. navigating inside a building with your phone.

</comment><comment><USER49> And hopefully we will get bluetooth audio that doesn't suck?

</comment><comment><USER50> Do I want longer range from bluetooth devices ?

I sort of thought the short range was, kind of, a feature ...

How far do you really want your mouse trails and your keystrokes to fly out into the ether ?

</comment><comment><USER51> I want better range, more bandwidth, less power consumption, and smaller footprint. Oh and make it super reliable.

One can dream...

</comment><comment><USER52> am I the only one, or does putting more radiation out into the environment pose substantial health risks.

All of this excess radiation is bound to cause some potential mutations in DNA. Adding even more is only going to increase the probabilities.

</comment><comment><USER53> Curious if these upgrades include any addressing security.

</comment><comment><USER54> I kind of want an 802.11z that does wifi over Bluetooth for sub-802.11a conditions. Am I weird?

<comment><USER55> IIRC there's already a spec for this, usually it's called something like PAN (Personal Area Network).

</comment></comment><comment><USER56> John Gruber from Daring Fireball has already written his review:

> "Next year it will work great" should be Bluetooth's slogan.

[http://daringfireball.net/linked/2016/06/10/bluetooth-5](http://daringfireball.net/linked/2016/06/10/bluetooth-5)

<comment><USER57> That's just gratuitously negative and dismissive.

Bluetooth 4 is actually not bad at all in my experience. Pairing is painless relative to old versions; sound quality is flawless; connections are quite reliable. The "strain" is to be expected around other devices since Bluetooth uses 2.4GHz, a very crowded band. I can't speak to the technical bits since I never looked at them, but my experience as a consumer has been positive.

Sure, it doesn't have the same range as a WiFi router, but it also doesn't use 1.5-20 watts (My source: [http://www.tpcdb.com/list.php?type=11](http://www.tpcdb.com/list.php?type=11))

<comment><USER58> Depends on the devices. My car, for instance, has about a 50% chance of successfully hooking up to my iPhone.

BT needs fewer features and better implementations. But apparently interop and reliability are not sexy enough for the BT standards folks to worry about. Can you imagine TCP/IP being in the same quality hole that Bluetooth is in?

<comment><USER57> Right, I agree that it depends on the device. A Chevy model I don't recall had the stupidest bug where you sometimes couldn't pair unless you reset the car computer... by leaving the driver's door open for 5 minutes.

I don't blame the Bluetooth standard though, messy as it might be. That's clearly terrible implementation on the car manufacturer's part.

<comment><USER58> BT seems over-complicated, especially considering that it's quite often low- level (I really mean that organizationally) firmware engineers working on products that won't be updated after they ship.

Given the types of products that are made with BT support, the hostile environments that they're developed within, and the common after-sales abandonment of support, BT should be a simpler protocol that is a LOT more resilient to implementation mistakes. But I don't think that anyone designs protocols to withstand institutional failure :-)

<comment><USER59> BT itself is not overly complicated. Bargain basement BT chips, which is what everyone ends up using to save pennies, are full of bugs that have to be worked around. Of the various BT stacks out there, only a few are actually good, and the good ones get to charge appropriate licensing fees, meaning that they aren't in wide use.

When you combine randChip with randBtStack, the end result is not necessarily a quality product. The poor engineers who have to work with this combination end up resorting to sending reset commands to their chip in an attempt to get the damn thing working.

<comment><USER60> It would be really interesting to have a list of good BT stacks and devices using them. That way maybe we could avoid the bad ones. As a consumer I have no idea which devices will actually work properly (and I assume Bluetooth as a whole sucks).

</comment></comment></comment></comment></comment></comment></comment><comment><USER61> But will it constantly fail to connect to devices it has been paired with a million times before?

Don't know how I could live without that "feature".

</comment><comment><USER62> Can't wait for nearby ads[1] to hit me from a far larger distance in the future.

[1] [https://developers.google.com/nearby/](https://developers.google.com/nearby/)

<comment><USER63> Yeah...

I think nearby is a really cool idea for many things, but I don't know if it is worth all of the notifications I will have to ignore from every billboard I walk by.

</comment></comment><comment><USER64> What does bluetooth not require support for multiple simultaneous devices. Have more than one device that won't let you connect more than one at a time.

<comment><AUTHOR> I think it's a bandwidth issue. If I use bluetooth mouse, keyboard, and headphones at the same time, the mouse becomes very sluggish. It works totally fine if I turn off either the keyboard or the headphone.

<comment><USER7> I suspect that comes down to the protocol used.

I had no problem connecting a keyboard and phone (as modem) to a N800 back in the day, while also playing music from the phone to a pair of bluetooth headphones. But that was if i used PAN For the data connection between N800 and phone.

If i used DUN, either the music or the data would occasionally skip.

And that may well be what gives Bluetooth its reputation. So many choices for the various OEMs in terms of protocols/profiles, on top of a more complex air interface (channel hopping).

Given all of it, one may well be better off comparing Bluetooth to USB than wifi. As wifi is Ethernet over a single radio channel.

</comment></comment></comment><comment><USER65> Oh anecdotes.

Use Bluetooth home spekaers, headphones and car radio all the time against my iPhone 6S - works really well.

What I do though is manually connect when I want this particular device to be connected (say my headphones in the gym), and then disconnect after use.

Might be magic trick most are missing.

</comment><comment><USER66> With all the Bluetooth car hacking going on and with the emergence of "connected cars" and self-driving cars, you'd think they would've introduced some stronger security features for Bluetooth 5.0 as well.</comment>


Qualcomm's 48-Core ARMv8 Processor Runs Windows Server - <AUTHOR> http://www.electronicdesign.com/embedded-revolution/qualcomm-s-48-core-armv8-processor-runs-windows-server <comment><AUTHOR> The company is releasing its 48-core Centriq 2400 processor, which works with Microsoft Windows Server and Linux.

<comment><USER2> Any idea on what will it cost?</comment></comment>


Why are 2D vector graphics so much harder than 3D? - <AUTHOR> https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harder-than-3d-graphics/ <comment><USER3> >This new printer was based on a small, stack-based Turing-complete language called Forth, and they named it… the Interpress!

Xerox's laser printers were never "based on Forth". JAM and Interpress were only conceptually related to Forth, in that they used postfix semantics.

That's like saying that because Java byte code uses a stack, your Android phone is based on Forth. It's not. Stack based architectures (like the Burroughs B5500 and B6500, developed in 1962, which directly inspired Design System => JAM => Interpress => PostScript) have been around a lot longer than Forth (developed in 1970), and simply using a stack doesn't make a language Forth.

Here's a much more accurate and detailed historical account of the history of Interpress, written by Brian Reid:

[https://groups.google.com/forum/#!topic/fa.laser- lovers/H3us...](https://groups.google.com/forum/#!topic/fa.laser- lovers/H3us4h8S3Kk)

Gaffney came to E&S from graduate school at the University of Illinois, where he had used the Burroughs B5500 and B6500 computers. Their stack-oriented architectures made a big impression on him. He combined the execution semantics of the Burroughs machines with the evolving Evans and Sutherland imaging models, to produce the Design System. Like all successful software systems, the Design System slowly evolved as it was used, and many people contributed to that evolution.

John Warnock joined Xerox PARC in 1978 to work for Chuck Geschke. There he teamed up with Martin Newell in producing an interpreted graphics system called JAM. "JAM" stands for "John And Martin". JAM had the same postfix execution semantics as Gaffney's Design System, and was based on the Evans and Sutherland imaging model, but augmented the E&S imaging model by providing a much more extensive set of graphics primitives. Like the later versions of the Design System, JAM was "token based" rather than "command line based", which means that the JAM interpreter reads a stream of input tokens and processes each token completely before moving to the next. Newell and Warnock implemented JAM on various Xerox workstations; by 1981 JAM was available at Stanford on the Xerox Alto computers, where I first saw it.

<comment><USER4> This is why I come to HN

<comment><USER5> This is why I usually check out the 2-3 top comments and then read the article.

<comment><USER6> Same here! I thought I was the only one with this strange habit.

</comment></comment></comment></comment><comment><USER3> >The only major problem with PostScript was its Turing-completeness — viewing page 86 of a document means first running the script for pages 1-85. And that could be slow.

1) EPS (which the article just mentioned) is part of Adobe's Document Structuring Convention, which solved the problem of skipping and reordering pages.

[https://www.adobe.com/content/dam/acom/en/devnet/actionscrip...](https://www.adobe.com/content/dam/acom/en/devnet/actionscript/articles/5001.DSC_Spec.pdf)

[https://www.complang.tuwien.ac.at/ulrich/PS/eps.html](https://www.complang.tuwien.ac.at/ulrich/PS/eps.html)

>Every DSC-compliant document is indicated by having the comment %!PS-Adobe 3.0 as the first line. This comment is a flag to indicate that the document is compliant. You should never use this comment unless your document really is DSC compliant. There are many other parts to proper DSC. A document which follows the DSC can be manipulated in many ways. In particular, postprocessors can shuffle the pages, print two or more pages on a side, and so on. The printer drivers from some notable companies do not follow the DSC, and their PostScript documents are, therefore, impossible to work with once they've been generated.

2) Inefficiently skipping pages (or being slow) is NOT the main problem with PostScript's Turing completeness!

[https://www.loc.gov/preservation/digital/formats/fdd/fdd0002...](https://www.loc.gov/preservation/digital/formats/fdd/fdd000246.shtml)

>Security Issues: In early 2017, Microsoft took steps to prevent exploits based on Word's import "filter" for EPS. Based on the assessment that "EPS files are a legacy format that has largely fallen out of favor in today's ecosystem", Microsoft disabled the import filter by default in its April 2017 security update for Office. According to PPTools post I can no longer insert EPS graphics into PowerPoint, this update applied to Office 2010, 2013, and 2016/365\. Import of EPS files into Office 2007 has been disabled since 2015. The stand-alone Office for Mac is not affected.

>A Jan 2017 post from The Register, We don't want to alarm you, but PostScript makes your printer an attack vector, publicizes the vulnerability of networked PostScript printers. The potential for damaging exploits based on communication between computers and PostScript printers has been understood for years, but was not a serious threat before PostScript printers were networked and accessible over the Internet. See also PostScript page from Hacking Printers.

[http://hacking-printers.net/wiki/index.php/PostScript](http://hacking- printers.net/wiki/index.php/PostScript)

<comment><USER3> Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other:

[https://groups.google.com/forum/#!topic/fa.laser- lovers/H3us...](https://groups.google.com/forum/#!topic/fa.laser- lovers/H3us4h8S3Kk)

>By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.

</comment></comment><comment><USER7> "Without getting too into the math weeds, at a high-level, we call approaches like Bezier curves and Hobby splines implicit curves"

I don't think of Bézier curves as implicit in any way. There's an explicit equation for the curve, as a parameter of "time" (0 at the beginning of the curve, 1 at the end, increasing monotonically in between).

<comment><AUTHOR> Yes. Technically they are parametric curves but you can turn any parametric curve into an implicit one (the reverse not being true), so I chose to leave out that small detail for narrative purposes.

<comment><USER8> >Technically they are parametric curves

It would make the already excellent article even better if you simply linked to the relevant[1] Wikipedia page.

Similarly, for 3D, you really want parametric surfaces[2], which NURBS are.

For the readers:

The key difference: to plot an _implicit_ curve, you need to _solve an equation_ , which is a whole another can of worms. Solving equations is hard. For high-degree equations, there are no formulas for solutions!

To plot a _parametric_ curve, you just need to plug numbers into some formulas. That's much easier!

The problem discussed in the article is that even if you have an _explicit parametrization_ , answering questions like "Where does this curve/surface intersect this ray?" involves equation-solving. And that's hard. As would be something like "represent this curve/surface with segments/triangles of uniform size".

TL;DR: _implicit_ is something for which you don't have a formula. Bezier and NURBS have easy formulas; they are _parametric_.

[1][https://en.wikipedia.org/wiki/Parametric_equation#Explicit_e...](https://en.wikipedia.org/wiki/Parametric_equation#Explicit_equations)

[2][https://en.wikipedia.org/wiki/Parametric_surface](https://en.wikipedia.org/wiki/Parametric_surface)

<comment><AUTHOR> The implicit form is what's used when rasterizing, because we have the opposite problem: we don't care about the value of a specific bezier function at specific time t, we care about whether the pixel at location x,y is on inside the path created by a number of bezier segments (but it's even more complicated, because of winding order). That can't be solved with the parametric form alone.

<comment><USER8> Indeed, but the terminology used in mathematics is very clear. So perhaps add this snippet to the article?

Another thing possibly of value: where Bezier curves come from - <USER2> design. The machines that were tracing these curves out needed to solve the forward problem (where should the tool head be at time _t_?), and the designers needed an easy way to change the shape of the curve. The Bezier splines were (and still are) a great solution to that problem.

For that reason, it's easy to convert Bezier splines into G-Code for either plotter - or, these days - 3D printer.

Also, sampling the parametric form does give you a polygon (or a polygonal mesh), which is easier to work with. But that's another can of worms.

</comment></comment></comment></comment></comment><comment><USER9> The Hyperdimension Neptunia games have character graphics that breathe and move and looking at them I thought they were vectors but when I looked into the resource packs I was astonished to find no whole-character CG's but instead bitmap eyes and mouths and shoulders and other parts that the system would transform and move around with the 3-d scaler.

Even to draw 2-d graphics the 3-d technology works so much better.

<comment><USER10> I think that's just an artifact of the fact that not nearly as much effort has been expended on 2D graphics as 3D. In fact, I've become convinced through my Pathfinder work that the GPU is just as good as the CPU for 2D vector graphics. It's just that our 2D rendering stacks are way behind.

(As an aside, I think this state of affairs is unfortunate, given how much money there is in mobile apps and browsers and the like. The vast majority of the research goes to 3D, and 3D is flashier and prettier work in a sense, but the amount of time we spend reading text on a screen generally dwarfs the amount of time people spend consuming 3D CG entertainment...)

<comment><USER11> If the GPU is only "just as good" why bother with GPU rendering at all? Free up the CPU for other work?

<comment><USER12> Yes, definitely. We did that in SimAirport, basically rendering everything as if it was full 3D and use none of the engine-provided "2D features" (which largely amounts to 'more work on the CPU').

Finding fun mechanics that add to CPU load is awfully easy. ;)

</comment></comment></comment></comment><comment><USER13> Nice to see a nod to Iniqo Quilez and the crazy SDF world. I still get a thrill from the fact you can specify an infinite grid of spheres with a single line of SDF code. Seems magical - as does the "almost free" CSG, morphing and chamfering you get from SDF rendering.

<comment><USER14> But why ' of incredible infamy ' \- did he do something illegal, bad or contemptible?

<comment><AUTHOR> It's a bit tongue in cheek and perhaps I should edit it out before someone misinterprets it. To a lot of people, iq is a mad scientist, in the best way. The rediscovery of SDF and invention of raymarching almost immediately gave every single graphics developer pause. It's such a different way to think about graphics and modelling and art and helped open people's eyes to alternate approaches and representations.

<comment><USER15> IMO, yes, it shouldn't be there. I've been following the guy for some years and was really surprised to see him called "infamous", so I went and googled for a while to see if he ever did anything "wrong".

<comment><AUTHOR> I adjusted the wording. Incredibly sorry about that, I definitely don't want to hurt the man's reputation.

</comment></comment></comment></comment></comment><comment><USER16> > Microsoft, while working on Windows 95, wanted to create its own graphics > API for developers, and a primary goal was making it compatible with > existing printers so the graphics could be sent to printers as easily as a > screen. This API was eventually released as GDI, a core component used by > every engineer during Windows's meteoric rise to popularity in the 90s.

AFAIK, GDI was part of Windows since the very first version released in 1985.

<comment><USER17> Yes, and its binary serialization format Windows Metafile (WMF) also predates Windows 95. Microsoft tried to push it as an alternative to PostScript for printing, with some success in low-end PC printers with thick drivers.

[https://en.wikipedia.org/wiki/Windows_Metafile#Implementatio...](https://en.wikipedia.org/wiki/Windows_Metafile#Implementations)

</comment></comment><comment><USER18> Apples to oranges...

The 3D equivalent of vector graphics would be Boundary Representation [1], which is multiple orders of magnitude harder than 2D vector graphics.

[1] [https://en.m.wikipedia.org/wiki/Boundary_representation](https://en.m.wikipedia.org/wiki/Boundary_representation)

<comment><AUTHOR> Absolutely. One could also come up with a 2D imaging model that does not rely on curves and is friendly to rasterization. My goal is to illuminate why when we say "2D vector graphics" we typically mean apples, and why when we say "3D" we mean oranges. Plenty of other imaging models exist for both 2D and 3D, but for better or worse these are the ones that stuck. Part of my research is investigating alternative imaging models that doesn't have the same influences, like the boundary representation, and seeing what falls out of it.

<comment><USER19> >My goal is to illuminate why when we say "2D vector graphics" we typically mean apples, and why when we say "3D" we mean oranges.

This premise in the article was pretty confusing as I do not think this is universal.

When I think of vector graphics I think of fonts (2d) and star wars cgi (3d vector death stars).

When talking about rasterizers, the modern pipeline of rendering 3d meshes to a 2d back buffer comes to mind.

It took me some time to understand the purpose of this article because I first had to understand that 2d meant vector and 3d was to mean raster in this article.

<comment><AUTHOR> 2D and 3D are both vector (as in, a mathematical description of the shape).

Typically when we say "raster graphics", we mean graphics already computed as a set of points, like a bitmap PNG file. But here 2D comes in as a set of curves, and 3D comes in as a set of triangle edges. Both are mathematical descriptions that have to be "rasterized", e.g. transformed from the edge representation to the raster one.

</comment></comment></comment></comment><comment><USER19> Is it just me or anyone else confused by the conflation of 2d to vector and 3d to raster graphics in this article?

</comment><comment><USER20> Bless you people, for revealing this concise and informative gem.

</comment><comment><USER21> The technical aspects of this article are super interesting, but also the aspects that talk about adobe's early business model: _Adobe's original business model was to sell this font technology to people that make printers, and sell special recreations of fonts, with added hints, to publishers, which is why Adobe, to this day, sells their versions of Times and Futura. Adobe can do this, by the way, because fonts, or, more formally, "typefaces", are one of five things explicitly excluded by US Copyright Law, since they were originally designated as "too plain or utilitarian to be creative works". What is sold and copyrighted instead is the digital program that reproduces the font on the screen._

An interesting way to look at this technology from a startup perspective. From the new industry of digital printing they found a business model based on the loophole that fonts are uncopywritable and could be monitized.

</comment><comment> Const-me I don't agree that 2D is harder than 3D. Regardless on what you count, a page of text is much simpler to render than a frame in modern videogame. Even if you don't cache TTF glyph textures.

I think it's just legacy. For many decades before modern GPUs, 2D graphics was done in certain ways. People accumulated experience, wrote books, taught stuff to students in university.

Then modern GPUs happened, but initially only gamers and 3D graphics professionals had them, so 2D programmers couldn't care less, their users just didn't have hardware for GPU-based rendering. I think it was only around 2008-10 when non-game developers could finally use GPUs without sacrificing users base, and even at that time it meant "DX9 GPU" so no geometry or compute shaders.

I think people will adjust after a while. Professors teaching 2D graphics will stop talking about moveto/lineto and start talking about submitting triangles and writing shaders.

<comment><USER22> > I think people will adjust after a while. Professors teaching 2D graphics > will stop talking about moveto/lineto and start talking about submitting > triangles and writing shaders.

The 2D graphic system in the future _will_ of course submit triangles and make use of shaders, but it is hard to imagine that we will be directly working with triangles. And we have taken the subtly broken scenary of raw 3D triangles granted (so far) but not tolerated jaggy 2D strokes. To resolve this dichotomy either 3D should go continuous (e.g. implicit surfaces) or 2D should go discrete as you suggest; the latter seems more unlikely.

<comment> Const-me > 2D graphic system in the future

"The future is already here, it's just not evenly distributed" © William Gibson.

It already works this way on modern Windows: WPF, UWP, and Direct2D already use GPUs.

> it is hard to imagine that we will be directly working with triangles

Most people doing 2D graphics on CPU don't moveto/lineto either, they use higher-level libraries for that. To be good at it, you have to understand, to some extent, couple underlying abstraction layers. That's why universities are teaching these basics. The basics for GPU-rendered 2D graphics are totally different, and until very recently only 3D graphics professionals cared about them.

> either 3D should go continuous (e.g. implicit surfaces)

You don't necessarily need implicit surfaces. If you have a GPU ≤ 10 years old, you can convert 2D vector stuff to triangles on the fly.

Here's a simple example that renders a polyline: [https://github.com/Const- me/vis_avs_dx/blob/master/avs_dx/Dx...](https://github.com/Const- me/vis_avs_dx/blob/master/avs_dx/DxVisuals/Effects/Render/PolylineGS.hlsl) It cuts a few corners e.g. doesn't handle self-intersecting polylines particularly well if you have transparency, but it's all fixable, that was an unpaid hobby project.

Often you can do the same with Bezier/Nurbs, see tessellation stages in D3D11 docs.

<comment><USER22> > It already works this way on modern Windows: WPF, UWP, and Direct2D already > use GPUs.

Oh, you are right. Even DirectWrite makes use of GPUs (and not just texture atlas) when you use a correct API.

> [...] That's why universities are teaching these basics. [...]

I agree if you meant so. It is unfortunate that most university courses are not concerned with fundamentals or only concerned with _outdated_ fundamentals.

<comment> Const-me > most university courses are not concerned with fundamentals or only > concerned with outdated fundamentals.

I don't think they're _that_ bad. For things that are relatively stable, like compilers, file systems, OS kernels, or relational databases, universities are doing OK job.

It's just that GPUs have been evolving too fast for the last decade. They drive evolution of everything that runs on them. GPUs have become ridiculously powerful (in my desktop PC, GPU is 25 times faster than CPU doing math on floating-point numbers), so more and more stuff does run on them. Initially they only run 3D game engines, then 2D graphics, now also a lot of high- performance computing. When stuff gets ported from CPU to GPU it changes a lot due to very different architecture.

</comment></comment></comment></comment></comment><comment><USER23> That's funny. I was just wondering weather Dreams was based on implicit surfaces, with their ability to scale their models in this good looking way, and then the article goes and mentions it as an example.

Edit: I really enjoyed the article and its information, but I think I missed the part where it answered the question in the title.

</comment><comment><USER7> Is it true that plotters were the first graphical device to be controlled by computers? before oscilloscopes?

Doesn't really make a difference to the point in the article. Both are "vector" devices. But I'm curious about the history.

<comment><USER24> I'd say looms, which would be raster devices.

<comment><USER25> I'd say a loom deals with vectors, it just only handles thin vectors in two directions 90 degrees rotated from each other.

</comment></comment></comment><comment><USER26> Thanks you for this extensive historical and technical overview. It's really useful to know where we are and how we got here. It's easy to underestimate how widespread the consequences of these fundamental choices are.

</comment><comment><USER27> I'd just like to say, I'm generally hard to please on software, but Blend2D is good stuff, those guys are s-m-r-t.

</comment><comment><USER28> Thank you for writing this up. The computing world needs more of these history articles.

</comment><comment><USER29> When I create a simple curved object in Blender or OpenSCAD, I see a mesh of triangles. When I create a simple curved object in Fusion 360, I see a smooth object with no apparent triangles. Is Fusion 360 rendering a triangle mesh or is it doing something else?

<comment><USER30> Fusion 360 (or FreeCAD) _renders_ a triangle mesh on-demand at display time from the underlying model. But that underlying model is based on solids with perfect platonic shapes like arcs, spheres etc. In Blender and OpenSCAD the underlying model is also based on triangle meshes, so they cannot do the same.

<comment><USER31> Are you sure about OpenSCAD?

I thought it used constructive solid geometry?

<comment><USER30> Kinda, but I primarily have a user perspective. For instance even though most of the OpenSCAD language operators are classic CSG ones, there are variables to specify the number of facets on circles etc (which does not make much sense in a pure solids world). This can be controlled globally using the $fa/$fs/$fn variable (assuming a well-behaved model). Changing these variable seems to require the entire geometry to be rebuilt. Rebuilding the model itself is slow, and it gets slower the more facets you have - indicating that this is not just a 'display' feature. I believe this is because the underlying geometry kernel, CGAL, operates on meshes.

Note that OpenSCAD can also export a CSG datastructure of a model. The OpenSCAD module in FreeCAD module uses this generate B-rep based solid models using their OpenCascade kernel.

This raises the point of difference between OpenSCAD and Blender. In OpenSCAD the mesh is mostly a secondary thing, an artifact of how the internals are implemented - the "primary" model the user modifies is the code itself. Where as in Blender, the mesh is the primary model being modified by user. Although the distinction is a bit blurred, as Blender has some support for NURBS these days. And one can have non-destructive operators ("modifiers") such as subdivide/array/mirror etc.

</comment></comment></comment></comment><comment><USER32> Because people keep turning them into HTML. Leave the vectors alone, people! CSS is terrible.

</comment><comment><USER33> This is a very interesting article, but it does have some errors. I'm no expert in the area, but here are some that I spotted.

> The first graphics devices to interact with computers were "plotters",

The first graphics devices used as such on _digital_ computers were the visible debugging CRTs driven from the Williams tube control signals, and of course "ASCII" art (before ASCII) on printers. George Dyson's book on the Johnniac has a lot of images of one-dimensional cellular automata from the dawn of the von Neumann machine. The TX-0 had a point-plotting CRT and also, I believe, the first pen plotter.

> The only major problem with PostScript was its Turing-completeness — viewing > page 86 of a document means first running the script for pages 1-85

As Don pointed out, that isn't the major problem with it being Turing- complete. Aside from the frequent security holes that have occurred, I recall a four-line PostScript .signature in the 1990s that computed an IFS fractal for 60 seconds and then printed it; it would plot more or fewer points according to whether your printer's PostScript was faster or slower, so it might not print out the same way twice even on the same printer. Writing a PostScript document that renders more or fewer pages is just as easy. And the common kinds of manipulations you'd like to do with printable documents are unnecessarily difficult with PostScript because of the Turing-completeness — if you implement them by assuming documents that claim to respect DSC will do so, your tools will break at random on real-world documents whose DSC compliance is imperfect. Consider the problem of concatenating two PostScript documents (pscat), each of which might have redefined "moveto" in its prologue, or defined "M" as a shortcut version of "moveto" with similar but subtly different meanings; or, worse, interspersing their pages, or displaying reduced images of their pages (psnup, psbook, mpage) on the same page. In theory you could hack together some kind of sandbox that makes this stuff work reliably, but in practice the solution is to distill the documents to PDF using GhostScript.

(For an overview of DSC, see the excellent Brian Reid paper Jasper and Don posted links to: [https://tech- insider.org/unix/research/1985/0301.html](https://tech- insider.org/unix/research/1985/0301.html))

Even my favorite PostScript test document (from Network PostScript Printer Installation Illustrated Through Interpretive Dance) prints a rectangle that is quite rarely the same size on different printers; it's even different sizes on the same printer using different paper sizes:

        %!
        clippath stroke showpage

> The only major problem with PostScript was its Turing-completeness… And that > could be slow. Adobe caught wind of this user complaint, and decided to > create a new document format that didn't have these restrictions

This is not really true. The original motivation for PostScript Distiller (before PDF stopped being a subset of PostScript) was to make a way to get documents onto computers that were too wimpy to run a full PostScript interpreter, like IBM PCs and Macintoshes. The problem was not, as I understand it, primarily that it was slow, and certainly not that it was Turing-complete (those machines ran lots of Turing-complete languages, after all) but that it required a lot of code and a lot of memory.

> It threw out the programming language — but the graphics technology stayed > the same.

This was only true at the very beginning. PDF (and SVG) has evolved quite a bit over the years. Notably, PDF and SVG support alpha-blending and gradients, while PostScript didn't, last I checked.

> Bezier curves do exist in 3D, where they are known as B-splines, and they > are computable, but they have the drawback that they limit the ways you can > connect your mesh together.

This is almost entirely wrong. B-splines as such are one-dimensional, or two- dimensional if you consider the abscissa a dimension, though you can of course construct parametric curves of any dimension each of whose coordinates is a B-spline in that dimension. They are not, in general, computable (and neither are NURBS surfaces, which I think are what is meant), but all of Bézier curves, B-splines, and NURBS surfaces are easy to compute particular points on, if their parameters are computable. B-spline surfaces in 3-D don't, as far as I know, have anything particular to do with Bézier surfaces, except in the sense that Catmull–Clark is a Bézier-like algorithm that converges to a cubic B-spline surface, and of course B-splines (in the sense of basis splines) and the Bernstein polynomials used by Béziers are just alternative bases spanning the same space of polynomials, so you can freely convert a parametric polynomial surface of a given degree between the two representations. Nor do any of Bézier curves, NURBS surfaces, or B-splines impose constraints on surface topology.

> we call approaches like Bezier curves and Hobby splines implicit curves, > because they are specified as a mathematical function which generates the > curve

This is almost entirely wrong; Bézier curves and Hobby splines are parametric, not implicit, and "specified as a mathematical function which generates the curve" is not what "implicit curve" means. The truth is close to the opposite: an explicit function is a mathematical function which generates the curve, while an implicit function just tells you which side of it you're on.

> The 3D equivalent of an implicit curve is an implicit surface, made up of > basic geometric primitives like spheres, cylinders and boxes.

This is very much not what an implicit surface is. The author has confused CSG ("constructive solid geometry"), which is making things up of basic geometric primitives like spheres, cylinders, and boxes, with implicit surfaces, which are almost, but not quite, completely unlike CSG.

An implicit surface is the solution set of an equation in three unknowns. If you want a sphere, that's easy: (x - 17)² + (y - 22)² + (z - 84)² = 39, for any values of 17, 22, 84, and 39. But a box? That's gonna be a bit rough: (x² - 1)(y² - 1)(z² - 1) = 0 _contains_ a box, but its sides extend to infinity. It's definitely feasible to hack the equation to clip them, but it's not what implicit surfaces are good at, and I think some of the obvious approaches make life a lot harder for solvers.

A much more typical example of an implicit surface, in my book, is Jim Blinn's metaballs — something like (x - 17)² + (y - 22)² + (z - 84)² + (x - 17)² + (y - 28)² + (z - 84)² = 39, which gives you a blobby barbell-looking thing. Although you might think that it should give you two spheres, actually no patch of its surface is a patch of the surface of a sphere, because the proximity distorts both spheres into non-sphericity.

Or, consider a paraboloid, the shape of a satellite dish or a Newtonian telescope mirror: x² + y² - z = 0 (though that particular example is easy to solve as an _explicit_ heightfield, so maybe it's not the best example of _implicit_ modeling.) That's gonna be a real pain to model with spheres and cylinders. You're never gonna get there if you're trying to get your telescope mirror to focus a clean image.

> 2D graphics started and maintained forward momentum around these implicit > curves, by near necessity in their use in modelling human letterforms and > glyphs. The hardware and software to compute these paths in real-time was > expensive

This is wrong; although some recent systems like Dan Amelang's Gezira do in fact compute paths from letterforms for every frame, none of METAFONT, GDI, and X11 do this, normally. Instead, all of them rasterize the letterforms early, then use the pre-rasterized letterforms over and over. PostScript is in kind of a weird gray area, but I'm reasonably sure that typical PostScript implementations do that most of the time as well, although you _can_ rotate text and blow it up to huge sizes, which necessarily requires re-rasterization at some point, and of course, ever since Type 2, you have "charpath".

> Surfaces like Catmull-Clark and NURBS allow for arbitrarily connected meshes > to empower artists, but this can lead to polynomials greater than the fourth > degree, which tend to have no closed-form solution

This is not, as far as I know, wrong, but is misleading; if you are computing quartic parametric surface patches, you are not going to do it by using Ferrari's closed-form solution to quartic equations. You are going to do it by subdividing triangles, just as you do for higher-order equations, because tabulating the (x,y,z) values for a lattice of (u,v) values is pretty simple actually.

> The difficulty, of course, is that only a legitimate genius like Quílez can > create Surfer Boy. There's no existing tooling for signed-distance field > geometry, it's all code

This is not even wrong; it's incoherent. ImplicitCAD is "all code", sure, but does that make it "no existing tooling"? And, not to bag on IQ here, who is legitimately super awesome, but SDF raymarching is not actually that hard to implement. You don't have to be a genius. You probably shouldn't take the word of someone who confuses CSG and implicit modeling about it, either.

Also, it seems a bit amiss to bring up IQ and Shadertoy in the same paragraph, but not mention that IQ wrote Shadertoy! (Though of course it's a team effort now.)

Anyway, I thought it was a really interesting article, and it introduced me to a bunch of research I hadn't seen. So it was worth reading. Just be careful about the errors!

</comment><comment><USER34> Revision of history, wrong, and insultingly so. This post is a rewrite of serious graphics history. Read Foley Dan Vam, forget this tripe.

<comment><AUTHOR> Parts of this post were based on the CACM'84 interview with van Dam. I cannot cover every single small development along the way. I had a paragraph on pre- Porter Duff 2D image models like QuickDraw, X11, and yes, Foley/van Dam's GKS but after a lot of hesitation, cut it for brevity. There are too many contributions to list, hopefully I can chronicle more in a future post.

The story I wanted to tell was to cover the large, broad developments in the industry that caused our solidification of the respective image models in both 2D and 3D. Perhaps I omitted a bit too much, and I'm certainly framing it with modern eyes, but I do not believe any of this to be revisionist.</comment></comment>


Mattermark Weekly Issue #1 - <AUTHOR> http://mattermark.com/mattermark-weekly-1-sent-sunday-june-9-2013/

<comment><USER2> I actually like the news summary aspect of this; if you combine quant news about financings with a few more sections (people moving jobs, maybe major startup news headlines), it would be a great way to stay on top of the market with minimal time.

<comment><USER3> Agreed. I think it would be nice to see company logos too, so that I can start remembering their brand, and generally just to mix up the heavy amount of text.

</comment></comment><comment><USER4> I think of myself as fairly plugged in to the startup scene. One data point that Mattermark is indeed doing what it claims—"to uncover the most promising private companies in the world"—is the fact that I haven't heard of most of these companies. I'm looking forward to future issues.</comment>


How (Not) to Write an iOS SDK - <AUTHOR> https://realm.io/news/altconf-conrad-kramer-writing-iOS-sdk/ <comment><USER2> I made it about 1/3rd of the way through this. Supporting all this guy's demands is probably much more time consuming than writing whatever the library originally intended to do.

Seems quite unreasonable to me. Perhaps a better way to write this would be describing how iOS's SDKs have too many variations in deployment to make them truly drop-in for everyone else.

<comment><USER3> I definitely laid out what I consider the "gold standard". Most open source projects hit some, but not all of the items on the list, for various reasons – and that's okay. It's certainly time consuming to work on some of these items, and the cost/benefit of each should be evaluated individually.

But there are quite a few developers that work on SDKs as a full time job, so hopefully they'll pick up on some of the items in the talk :^)

(as for the fragmentation in the iOS ecosystem in general… that's a topic in and of itself)

</comment></comment><comment><USER4> Writing your library in Objective-C is silly if you mean to use it from Swift. The languages are incredibly different (value types, powerful protocols, generics vs. just objects and simple C types), so you'll heavily limit yourself by writing in Objective-C. Nullability annotations don't really make up for that. If you're using Swift, don't limit yourself by writing your components in Objective-C.

<comment><USER5> You miss his point. It is much easier to consume Objective-C API from Swift then consuming swift API from Objective-C. Even more so if you need the library integrated at a C++ layer of your app.

<comment><USER4> I didn't miss his point. I _disagree_ with it. Using Objective-C sacrifices so much that is great about using Swift, and the continually-shrinking Objective- C-only developer market doesn't make up for the loss of all of the Swiftyness.

C++ layers are rare for framework authors, so I don't think that the idea of them should be used to dissuade people from writing Swift frameworks. Obviously, if you need to integrate with C++, use a language that can.

<comment><USER5> There is still a massive, massive amount of enterprise software (see: everything at Apple) that has millions of lines of code in Objective-C. That code will never be rewritten. If you have millions of dollars riding on a framework/app in Objective-C the business needs outweigh any perceived language niceties you get in swift.

This aside - I also disagree with you, Swift is a worse language in a lot of ways, not to mention the extreme compile times and purely unfinished concepts, as well as bugs related to seemingly foundational things like auto-created initializers for structs not getting picked up properly by sourcekit.

<comment><USER6> The macOS Dock and services handling infrastructure has already been rewritten in Swift.

More macOS components will be slowly rewritten in future OS versions.

Likewise some new Sierra APIs like Units are Swift only.

See this year's WWDC talk about Swift 3.0.

<comment><USER7> NSUnit looks to have an ObjC API?

[https://developer.apple.com/reference/foundation/nsdimension...](https://developer.apple.com/reference/foundation/nsdimension?language=objc)

<comment><USER6> I wasn't aware of it, thanks for pointing it out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> There are a lot of demands/needs/wants in this press that really only make sense to me if I'm writing a commercial SDK. If I've written an SDK as a support library for one of my projects and I want to open-source it or release it in any way, it'll include the language and build system support for my project.

If anyone else find that helpful, great - that's why I released it. If you 'require' me to add cocoapod support, when I don't use, now, or understand the intricacies of cocoapods, then that' bad for both of us (I probably can't support you properly when it breaks).

If the audience for this is really the Dropbox-types, i.e. their products live and die on integrations and SDKs, then this makes more sense...

<comment><USER3> Another interesting possibility is that when you release the library with your preferred build system and language, people can contribute additional ones :)

</comment></comment><comment><USER9> Just wanted to say: This is an excellent way to present this talk. The videos and slides synchronized on the screen, the transcript (looks like a slightly edited one, or perhaps the "shooting script", but still...) with links that jump in the video to the correct time.

Really, really well done.

Nice shirt, too. :)

</comment><comment><USER9> One small nit: Apple really doesn't want people using two-letter prefixes for their components. I know that's a pretty sore subject for a lot of iOS devs, but the example WFOAuth2 (where WF is the "Workflow" prefix) would be frowned upon.

The Workflow app itself, however, is spectacular, and I use it all the time. I use it to log arbitrary stuff to HealthKit (like when I drink a caffeinated beverage, for example).

<comment><USER3> You are right! I was considering using WFO, but decided to go with WF (which is what we use for Workflow).

Great to hear that you enjoy using Workflow :D

</comment></comment><comment><USER10> Seriously, thank you for writing this. I just started writing an iOS SDK days ago and had already made the mistake of starting off with Swift rather than Obj-C. Luckily I've only written 250 lines of code, you saved me hours of technical debt!!

</comment><comment><USER11> >As such, it's critical that you write your SDK in Objective-C so that the people that don't ship Swift can actually use your SDK.

I'm not an iOS developer but aren't Swift and Objective C files interchangeable?

<comment><USER12> Almost all Objective-C APIs can be accessed from Swift. (The one exception I know of is that a type which is a class with protocol conformances, e.g. `UIViewController<UIPickerViewDataSource>`, cannot be represented exactly in Swift. You can still use APIs with such a type, but the type will be different in Swift.) So if you implement your API in Objective-C, you're guaranteed that it's usable in Swift (though perhaps not idiomatically).

There are multiple Swift constructs that cannot be exposed to Objective-C, such as enums with associated values, structs, and global variables and functions. So if you implement your API in Swift, you have to be careful if you want it to be usable from Objective-C.

Another problem with writing your API in Swift is that the Swift ABI isn't stable yet. It changes between compiler versions. This means that your API (if written in Swift) __must __be compiled with the same Swift compiler as the user 's code. If you want to distribute your API as a binary-only library, you'll have to release a new version every time Apple releases a new version of Xcode, and your user will have to be sure to get the correct version of your library for their version of Xcode.

<comment><USER4> > The one exception I know of is that a type which is a class with protocol > conformances, e.g. `UIViewController<UIPickerViewDataSource>`, cannot be > represented exactly in Swift

Sort of doable with generics, but only from Swift code:

        <ViewController: UIViewController where ViewController: UIPickerViewDataSource>

</comment></comment></comment><comment><USER13> Good information. Thanks for posting this.

</comment><comment><USER14> The HN title lacks the iOS part of the headline - which is quite important because all the information is useless if you are not interested in iOS.

<comment><USER15> Agree. I closed the tab after reading iOS in the headline.

<comment><USER16> Me too.</comment></comment></comment>


PEAP-MS-CHAPv2 Authentication Could Allow Information Disclosure, Windows Phone - <AUTHOR> http://technet.microsoft.com/en-us/security/advisory/2876146

<comment><USER2> RADIUS guy here. I've worked with 802.1X and PEAP for as long as it's existed.

This isn't news.

If you disable certificate checking, then the authentication security of TLS goes away. Your traffic is still encrypted, but you have no idea who you're talking to.

This means that the attacker gets access to the MS-CHAPv2 data. Which we know can be attacked off-line via dictionary attacks.

Always enable certificate checking for 802.1X. If you don't, you're handing your authentication credentials to anyone.

And always know _which_ certificate you're checking. Some deployments use certificates signed by a known root, and for "ease of use", allow any certificate signed by that root.

Well... the root CAs sign thousands of certificates a day. You've just configured your system to hand authentication credentials to anyone.

Don't do that.

<comment><USER3> The thing is (as demonstrated in the actual presentations) the default is insecure and the process for making it secure is not straight forward.</comment></comment>


Ask HN: Is OpenGL Worth Learning? - <AUTHOR>

With Vulcan the next API to replace OpenGL... is it safe to assume that anyone that wanted to learn it is better off waiting for Vulcan? <comment><USER2> Yes. If you want to learn I'd still pick up OpenGL for now. The reason is conceptually you still need to master that level of development one. Two vulkan will not be ready for actual production use likely for maybe 12-18 months if I understand where it sits today. The marketing site for it says initial specs expected this year. Plus it was just really announced in March. So OpenGL isn't going away anytime soon, and even the way vulkan seems positioned so far, it isn't so much a replacement to OpenGL as it appears to be a Lower level framework.

Edit for clarity

<comment><AUTHOR> thx for the reply.i grandstander that if one learns a graphics API, it is easy to adapt to another,and OpenGL has NOW all the textbooks and experts online an tutorials... and Vulcan will not have even after an implementation comes out. BUT the time investment to learn OpenGL is huge.. and i don't understand if Vulcan will eventually replace OpenGL or they will coexist; or if Vulcan is more streamlined easier to learn more flexible. If the answer is that the industry will shift to Vulvan because OpenGL will be phased out, then it's maybe better to wait. i just don't want to sink a lot of time in condemned tech.

<comment><USER3> What is your goal? It is hard to suggest what you should do if we don't know your goals.

To do 3D programming you need to understand a lot of stuff - the math, shaders, how the GPU works, etc. All of that is invariant - you will need to know that stuff regardless of what API you choose because you are programming a GPU at a fairly low level. Of course, the details will change (GLSL shader, or something else) depending on the API.

But you will not, for example, get a job using Vulkan if you have been sitting idly not learning this stuff, waiting for Vulkan because your competition will have been programming in OpenGL for years already. You can write a game, make a product, now in OpenGL (or DirectX). Is your goal 3d programming, and you just want to know the best API to start with, or is this "OpenGL, or maybe Hadoop, or maybe machine learning" type of question with no specific goal in mind.

<comment><AUTHOR> My goal is to learn a lot of stuff in game development gameplay/audio/ai programming. I don't want to be an engine programmer or a rendering specialist, but I want to know how to do it if someday i will have to (help) code one. Graphics API are hard, so i wanted some opinions from those who know OpenGL and what was known as OpenGL-Next. I understand what you say: learn OpenGL now , it't here, you can work with it and if something better comes up learn the things that are new, but i want to optimise my time and avoid frustration. I can learn more about AI/audio etc in the meantime if that means that i will learn a more modern, powerful, logical API later.</comment></comment></comment></comment>


Modern garbage collection - <AUTHOR> https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e <comment><USER2> When latency matters and serving requests one could just do the old trick (popular in the Erlang world): implement the whole request serving in one light weight (Erlang) process, allocate, allocate, and kill the process at the end without the need to garbage collect. Give a fresh process to each request.

<comment><USER3> I think this is similar to an approach I saw in code from 1990s written in c++.</comment></comment>


RDF.rb: A Public-Domain RDF Library for Ruby - <AUTHOR> http://blog.datagraph.org/2010/03/rdf-for-ruby

<comment><USER2> Looks like a fun project but without RDFS inferencing, may not be too useful. Without at least RDFS inferencing (and OWL would be nice) I don't know how you can merge data from different sources using (for example) different property names that have the same 'meaning', etc.

<comment><USER3> Mark, you could use the RDF::Sesame plugin (<http://rdf.rubyforge.org/sesame/>) to interface to Sesame, which does inference for you. There is also an in-the-works RDFS gem (<http://rdfs.rubyforge.org/>) that will provide RDFS++ natively in Ruby for any RDF.rb-compatible graph or repository.</comment></comment>


DOJ defers payments to local police agencies through asset forfeiture program - <AUTHOR> http://www.usnews.com/news/politics/articles/2015-12-24/us-postpones-payments-to-police-in-asset-forfeiture-program <comment><USER2> How is civil forfeiture(cash register justice) not a constitutional violation?

The 4th Amendment declares that citizens have a right to "their persons, houses, papers, and effects, against unreasonable searches and seizures" and that no warrants may be issued without a statement of probable cause "particularly describing…things to be seized."

The 5th Amendment says the accused criminals shall not be "deprived of life, liberty, or property, without due process of law."

The 6th Amendment ensures that people accused of crimes must be "informed of the nature and cause of the accusation,"

The 8th Amendment forbids the government to impose "excessive fines" or "cruel and unusual punishments."

Opponents of the change have little more than 'the ends justify the means' as a counter argument.

<comment><USER3> The loophole relied on is that you aren't seizing "their" property, you're seizing property of unknown ownership. The onus is on the purported owner to prove it belongs to them so they can have Constitutional rights in it.

See [https://en.wikipedia.org/wiki/In_rem_jurisdiction](https://en.wikipedia.org/wiki/In_rem_jurisdiction), [https://en.wikipedia.org/wiki/Civil_forfeiture_in_the_United...](https://en.wikipedia.org/wiki/Civil_forfeiture_in_the_United_States) and [https://en.wikipedia.org/wiki/Asset_forfeiture#United_States](https://en.wikipedia.org/wiki/Asset_forfeiture#United_States)

Note that the government can admit the person used to own it. Under [https://www.law.cornell.edu/uscode/text/18/981](https://www.law.cornell.edu/uscode/text/18/981), property used in certain crimes belongs to the government, and so the government takes it. It's then the person's job to prove it was not involved in a crime. Courts have ruled this doesn't violate anyone's rights.

(I probably have some of this wrong, IANAL, but I gave sources so you can look those up.)

<comment><USER4> What I don't understand is how courts can assume it's used in a crime before a crime has been proven in court.

Presumably, if I can prove I earned/bought something, and am not convicted of a crime, turf the government seizure is wrongful and I should get restitution, but from what I read, that doesn't work?

<comment><USER3> Only persons have the presumption of not being guilty. Not property. The government can claim crimes all they want, they just can't claim a person committed a crime (and punish them for it).

This is all about shifting the burden of proof to the accused. Allowing the money to be charged separately does that, or so courts have ruled.

(Insert above disclaimer here.)

</comment></comment></comment></comment><comment><USER5> "the Department is deferring for the time being any equitable sharing payments from the Program" seems pretty explicitly to be a temporary suspension of payouts from the program, not a closure of the entire program.

"We explored every conceivable option that would have enabled us to preserve some form of meaningful equitable sharing. ... Unfortunately, the combined effect of the two reductions totaling $1.2 billion made that impossible." Doesn't seem like they wanted it closed to me.

How is this not just positive spin on a doj money grab?

<comment><USER6> > How is this not just positive spin on a doj money grab?

While the _best_ case scenario would be the entire notion of any asset sharing program be made outright illegal [0] because it has been shown to be corrupt, etc, etc - simply having it shut down is a good thing even if not for "good reasons" because at the very minimum, it means that if and when the program is reinstated, it will force conversation of the issue, something that has gone largely un-discussed in the American political landscape.

[0]: I personally would argue it should be illegal regardless of conviction, otherwise it incentivizes police forces and DAs to only go after high payout crimes

<comment><USER5> "it means that if and when the program is reinstated"

I'm saying it was never cancelled

<comment><USER7> Well now the argument can be made while the program is down. Why have the program if it's not doing it's thing?

</comment></comment></comment></comment><comment><USER8> I really hate that our legal system has, to a large degree, decided to a very, very narrow and very literal implementation of the Bill or Rights rather than going with the Spirit of the law. Civil asset forfeiture as practiced by the government is very clearly contrary to 5th amendment. But since it's using a bullshit legal loophole of suing the property and not the owner and doesn't violate the literal words it's A-OK!

<comment><USER9> The legal system has not narrowly interpreted the Bill of Rights. For example, the First Amendment has been construed to preclude lots of restrictions on conduct that is not literally "speech." Everything from contraception to abortion to gay marriage has become a "right" even though nobody can point to the specific amendment that guarantees it.

In the case of civil asset forfeiture, central to the Supreme Court's upholding of those laws was the fact that laws providing for civil forfeiture of contraband property were passed by the First Congress.

<comment><USER10> The US constitution itself explains what is apparently mysterious to some people. Rights are not enumerated. Indeed, as long as they do not impinge on the rights of others they are limitless. Otherwise our rights would be mired in the context of 18th c. morals and technology, and would require constant amendments to keep up.

We have a right to use encryption. Cryptocurrency. CRISPR. Etc. We have those rights. Why? Because nothing in the constitution says we don't. Otherwise the constitution would be unmaintainable.

<comment><USER9> A statement that a list of rights is non-exhaustive does not mean they are limitless. The purported right must be found somewhere else. E.g. Buying alcohol on Sundays is not prohibited in the Constitution, but you don't have a right to that because blue laws were accepted at the time.

Your idea of limitless rights turns Constitutional democracy on its head. Rights are exceptions to the power of the majority to regulate society. Limitless rights curtails democracy to nothing.

<comment><USER10> Your example about blue laws says nothing about rights. Blue laws regulate commerce but they don't prohibit anything outright. You can still drink on Sunday. If that restriction were to become too burdensome, a constitutional care could be made against it.

</comment></comment></comment></comment></comment><comment><USER9> I think you will see more of these moves going forward. As the hysteria of the 1990's starts subsiding and baby boomers start retiring, some of the worst police abuses are going to become politically untenable to defend.

<comment><USER11> Your comment caught my interest. Can you expand of the reasoning a bit further?

<comment><USER12> Post-vietnam war the US became a lot more conservative. 1980's saw "trickle down economics" (giving money to rich people would trickle down to everyone, seriously), increased mandatory jail times, three strikes laws, increased funding for war against drugs, white flight from the cities to gaited communities. A lot of these trends seem to be slowing or even reversing a bit, one can hope.

<comment><USER13> On trickle-down economics:

It is true that rich people tend to fund things like large businesses, which then pay middle-class workers. However, giving them free money gives them no reason to actually use that money to fund more businesses. Why invest when Uncle Sam gives you an allowance?

Solid reasoning, terrible plan.

<comment><USER8> Cut out the middle man and just pay people directly.

<comment><USER13> I do like the Basic Income Guarantee, but have yet to do any math on how efficient it is compared to the US's welfare system.

Ideally, the money would come in the form of a standardized cheque, to be handed out once a month to anybody who is 18 or older and can come to the local DMV and provide proof of citizenship. Unclaimed money goes toward funding the program, getting more workers into DMVs to handle traffic, and (again, ideally) could be sent to a charity of the recipient's choice.

</comment></comment></comment></comment></comment></comment><comment><USER14> This is legalized stealing. Targets were often not criminals but people with valuable assets.

</comment><comment><USER15> This is really great news. Asset forfeiture should only happen after someone has been convicted of a crime.

<comment><USER16> They didn't shut down the asset forfeiture, they shut down the sharing of seized assets with local police forces.

Their budget was cut, so they said "we need ours, pony up."

Likely, police forces which relied on federal statute to get 80% of the seized resources will now resort to state statute to maximize what they can take from seized assets.

<comment><USER15> It removes the federal loophole and it makes it a state problem. In the past, police would team up with feds to get around state laws.

Yes, it's still a problem but it's much more manageable now.

</comment></comment></comment><comment><USER17> Long overdue, this has been an obvious yet growing problem for decades. Asset forfeiture needs to be ended completely. This is only the first step.

</comment><comment><USER18> "This program was found to be corrosive to the integrity of our justice system, incompatible with American values, and thus we are terminating it immediately"

vs.

"We're keeping the money, LoL"

</comment><comment><USER19> This is surprising good news.

Took me three tries to read "defunds" properly, not as "defends".

<comment><AUTHOR> To be fair when I posted it autocorrect changed it to "defends" and I had to change it back

</comment></comment><comment><USER20> The article didn't answer the question, and I very curious -- if you're basically taking people's property and keeping 20% of the rake, how do you manage to lose billions in the process? Is it that the 20% is actually allocated elsewhere, or that asset forfeiture is somehow more expensive than I'd granted?

</comment><comment><USER21> Why isn't asset forfeiture an issue in the presidential campaign?

</comment><comment><USER22> All police revenue should go in a pool at the national level, and be randomly distributed to all states. "Protect and Serve" not "Loot and Pillage".

<comment><USER23> "police revenue": that's terrifying. How is turning law enforcement into a legally protected extortion gang a good idea?

<comment> shawn-butler Because that is what it is. There's nothing wrong with calling a duck a duck.

</comment></comment></comment><comment><USER24> Even if unintentional this is a step in the right directions because it removes the incentive for bogus civil asset forfeiture.

</comment><comment><USER25> The ratio of criminals is probably about the same in law enforcement and the general population.</comment>


Show HN: Spritz clone in 33 lines of TypeScript. Long words are displayed longer - <AUTHOR> https://typescript-spritz.stackblitz.io
License is Public Domain/CC0 and the code is here: https://stackblitz.com/edit/typescript-spritz
PS: This is a really quick hack because my Spritzlet license ran out and I hated that Spritz doesn't show long words longer than short words for a long time.
Spritz Homepage for reference: https://www.spritz.com/ <comment><USER2> This is awesome.

I know it's just a quick hack, but I'm curious about this in the code:

      200 +(30*word.length - 7)

I've never used TypeScript, but I'm assuming this is the same as:

      (200 - 7) +(30*word.length)

But I guess you meant:

      200 +(30*(word.length - 7))

<comment><AUTHOR> Thanks! I fixed it. (And added slider)

</comment></comment><comment><USER3> Error in /~/index.ts (19:21) Cannot read property 'replace' of undefined

<comment><AUTHOR> Can you please report the exact browser version and platform you are using ? I will try to fix it.</comment></comment>