We’re super excited to introduce a new member to our catalogue – League Spartan. We’ve been working on this one a while, and we’re starting out by releasing a single, bold weight. It’s a beautiful, modern geometric sans-serif, and we’ve actually been secretly using it on our own site for the last few months. It’s superb. You’ll love it.
Festival de tipografia de Madrid. Conferencias, exposiciones y talleres sobre tipografía, caligrafía, lettering y diseño tpográfico actual.
TypeMad is an upcoming festival of typography in Madrid: Conferencias, exposiciones y talleres sobre tipografía, caligrafía, lettering y diseño tpográfico actual!
Crafting Type is participating with a workshop the weekend before the main event. The key instructor is Octavio, a Spanish type designer, and if more than 15 people to sign up then Dave Crossland will join. If more than 30 sign up, Alexei Vanyashin will bring some Russian expertise to town!
El taller será en Inglés y español.
The workshop will be in English AND Spanish.
Its our standard 3 day workshop, but we have a special offer for the festival - there is only the ‘student’ price, with an additional discount - so the total for all 3 days is only €160.
The release of GNOME 3.14 is slowly approaching, so I stole some time from actual design work and created this little promo to show what goes into a release that probably isn’t immediately obvious (and a large portion of it doesn’t even make it in).
<iframe class="image full" frameborder="0" height="500" src="http://www.youtube.com/embed/Co4i_d47e1I"> Watch on Youtube </iframe>
I’d like to thank all the usual suspects that make the wheels spinning, Matthias, Benjamin and Allan in particular. The crown goes to Lapo Calamandrei though, because the amount of work he’s done on Adwaita this cycle will really benefit us in the next couple of releases. Thanks everyone, 3.14 will be a great release*!
<footnote>* I keep saying that every release, but you simply feel it when you’re forced to log in to your “old” GNOME session rather than jhbuild.</footnote>
In the last six weeks or so, I’ve given three talks about open source / free software in automotive. [That means "cars."]
It’s sort of a new thread for me to play out on the conference circuit, at least as a speaker, but it is actually an area that I have found personally interesting for ages, and in which I’ve been a secret hobbyist for a while—at a very amateur, “enthusiast” level. But after having followed the topic and having read up on it, last fall (i.e., November 2013) I decided to dive in and start experimenting with a Linux-based automotive computer build in my car.
That’s one of the talks I spoke about earlier: I gave a “build talk” about the project at the Automotive Linux Summit in Tokyo in early July. The goal was to relate my real-world experience (surprises, pitfalls, etc.) to the developers and strategists at ALS in the hope that it would be beneficial to them. I gave another talk at ALS about automotive security, but it consisted of “research” rounding up other people’s research and published studies about software security problems in car computers. I highly recommend the “just talk about other people’s hard work” methodology as a talk-development approach; it’s far less time-consuming than doing all the tests and paper writing oneself, and you also don’t have to apply for grants.
The third talk was at GUADEC, the annual GNOME project conference. It started out, in theory, as another “my build and what you can learn from it” talk idea, but it quickly became clear to me that I needed to do more: provide some context for the audience that didn’t already pay attention to the automotive corner, and offer some reasons why they should look into it and maybe even get involved. The GUADEC team ended up asking me to make that talk a keynote, which was definitely a surprise, but obviously lots of fun, too.
I tried to include some words on where I thought GNOME developers could get involved in automotive projects (especially since many of those projects already use GNOME libraries, even if they aren’t interacting too much with GNOME-proper upstream), and some ideas on how GNOME could be more “garage friendly.” More on that later. Nobody threw any vegetables, and a lot of people asked questions afterward, so I think it went well on the whole.
Interestingly enough, while working on the GNOME talk I kept running into the realization that a lot of full-time Linux folks weren’t really up to speed on the scope and makeup of the automotive Linux space. It’s understandable—most of the work now is pre-production and it may be a while before products hit the showroom floor. But that also makes it the best possible time for free-software people to get involved. The better you make it right now, the better it’ll be when it arrives at the dealer.
The other big take away, for me, was that evidently I’m a shamefully bad example of a tech hobbyist because I haven’t done a running “build log” on some personal blog site or on Instructables, detailing the ups and downs of shoehorning a homemade IVI system into a recent Mustang. So I’m vowing to do better on that front. But I can tell you this much: a lot of what goes into posts like that won’t make a lot of sense unless I dole out some background info, like I did at GUADEC. I apologize if you happen to catch this blog via Graphics Planet and you don’t care about the topic at all — but there is some interest UI/UX work a little later on in the process, I promise.
Anyway, here are the broad strokes if you’re just hearing about automotive Linux for the first time. The Linux Foundation has done this “ALS” conference for three(ish?) years now. ALS attendees tend to be drawn from three major projects: GENIVI, which is a multi-company consortium founded by folks in the automotive industry, Automotive Grade Linux (AGL), which is a working group coordinated by the Linux Foundation, and Tizen IVI, which is a distribution project run mainly by Intel and Samsung people. And there are, of course, plenty of other participants.
These projects overlap a lot in their areas of concern, naturally, but there are also big differences in what they want to accomplish, which makes a difference if you’re picking and choosing as an outsider.
GENIVI is focused on defining a platform-level Linux system that the participating companies can use as a specification to build their automotive products against. GENIVI defines components needed for in-vehicle infotainment (IVI; that’s the head-unit computer that the driver and passenger fight over while they’re barreling down the road) systems, so that car makers and suppliers don’t have to reinvent the wheel every time or argue endlessly about design specs. I.e., everybody uses GENIVI, so It Works. Naturally, the alliance has to write components that don’t already exist, so they do that: they have open source code at projects.genivi.org
But GENIVI is not defining the entire system; they are stopping right below the application API layer. Apparently that’s something that different members want to head in their own direction on, and potentially compete on. So GENIVI’s Linux builds tend to be more like “starting points for a company making a product in house.” They even use Yocto.
Tizen IVI, on the other hand, is designed to be a fully functional Linux distribution. It’s supposed to be something an OEM can grab and mold a product out of.
In that sense, it competes with GENIVI, I guess, but Tizen also has this interesting “cross-device-profile” concern. The larger Tizen project wants to make a Linux stack for consumer electronics products of all types (phone, smartwatch, TV, smartfridge, smartcoffepodmachine, etc) that can offer the same app-level API to third-party app developers. That is, you write yer Angry Flapbird game once, and it runs on all the devices. So Tizen IVI is very much concerned with that app layer that GENIVI isn’t. Tizen IVI may differ a lot under the hood from Tizen Mobile, but it’s the same on top. The app-level API is based on HTML5 and a lot of W3C standards.
Last but certainly not least is AGL. AGL is technically a “workgroup,” which means that it’s a bunch of companies that want to get together for some common purpose; they can work on whatever they decide to. At the moment, their most visible effort is the AGL Reference Linux distro, which is a fully installable Linux distribution that you can put in a car. It’s probably not quite the same as you will see in production vehicles, but it’s the closest thing to fully realized IVI of the existing projects. It’s based on Tizen IVI with a lot of additions. The additions include a suite of actual IVI apps (music player, navigation, vehicle status, phone hands-free tethering, etc).
Developing more such applications is another one of AGL’s focus areas; right now they’re putting feelers out for people to write apps; it’s actually a good opportunity if you want to do development. The other thing to remember, though, is that AGL may have broader interests than just IVI: they could decide to delve right into engine-control stuff as well, which is an entirely different space. Fuel injection, timing, traction control, etc.—all that stuff is computerized, and I hear interest from the hallway track in using Linux to virtualize, containerize, and improve these systems. It’ll be interesting to see.
All that background aside, I did actually talk about my personal “shadetree mechanic” project at both ALS and GUADEC. What I have is something on a very PC-like microITX motherboard, stuffed into the trunk space of a 2005 Mustang GT. How well does it work? Well, that depends on what your criteria are. I’ll give this one teaser thought, as I contemplate writing up a Proper Build Log like the wise & benevolent Makers Of Olde tell us we have to do:
If you make careful hardware choices, you can put together a functional Linux-based IVI system in your own car. If, that is, you have a reasonably modern car, sufficient time (or, alternatively, money) to put into the build from both the hardware and software sides, and if you’re willing to get your hands dirty. Literally dirty. And figuratively.
BUT. The first thing you’ll learn is that there is no such thing as a generic car or a generic car computer. The PC may be pretty standardized, but it also makes a lot of assumptions—like having a flat surface, with decent airflow, and a normal AC-DC power supply, and room to put stuff where you want it. None of those things hold true in a car, and every single choice you make, starting from where you think you’ll put the actual computer part physically in your vehicle, radically alters all of your decisions further down the line.
So it’s one individual builder’s story, and everyone else’s will differ greatly. But I also think the experience is useful for other FOSS developers to hear about, since whether you know it or not, automotive computer products are making their way to the mass market. And we don’t want Linux to be late to the party, having not thought about what it will look like when there’s a full-on computer in the car parked outside the house. How do we expect that computer to relate to our other computers? To connect to the network at our house? To interact with the portable devices we own and might bring with us? To the documents we ferry around?
It’d be good to have answers to those questions when the tidal wave of car PCs hits. Estimates are it’s less than a year and a half from now before the first official GENIVI systems hit showrooms. Proprietary software will take several iterations to get all this stuff right, and it will compete within itself, pretty fiercely. But I hope we won’t let them have the open road all to themselves.
While we’re figuring out our routines to come back to writing after an August of holidays, here’s a quick write up our ventures since February this year.
In March, Ana participated in the MiniDeb Conf Barcelona. She presented the Libre Graphics magazine in a talk about libre methodologies in design and in the production of physical objects. The slides of the presentation are here and there is also a video of the full presentation.
In April, we assembled and made public the first instance of the Kit Gráfica Livre (Libre Graphics Kit). It’s a portable safebox with a USB cable, containing a read-only SD card reader.
Placed in the bar of the Porto Fine Arts Faculty, it makes available a set of libre software for graphics and audio production. Besides software, people can find a collection of libre assets, such as typefaces, publications, typography books and a selection of F/LOSS manuals. All for free copying — while at the bar, anyone can pick up the box and use the USB cable to copy everything to their computer.
Our plan is to bring free culture and free software closer to students with this kit. There is an ample amount of open and free materials, tools and assets, but they are very often disregarded in the teaching of arts and design. We would like to see more kits in other arts&design schools, so get in touch if you would like to run one in your school. There’s also a plan for regular updates with new assets and tools.
We’ll keep posting about this mutating kit. In the meantime, there is a mini site for this project here.
In May we were at the Libre Graphics Meeting 2014 in Leipzig. Our talk, titled “Dear designer, have these cool tools”, was a about our desire to make distro that could introduce designers to libre tools and mindset. And help designers already using libre tools to persevere in this still arid land. We showed the Kit Gráfica Livre as one of the steps building up to this ambitious plan.
The Open Legislative Data Conference in Paris II took place in the end of May. Having been involved in the early stages of the Fabrique de la Loi, a visualization tool for the French law, we attend to present our latest open data project, Data Central. You can read more about in this OKFN Labs post. Videos and slides from the presentations are available here.
In June, we gave an interview in the portuguese podcast DAR em Conversa Aberta.
Design Advanced Resources (DAR) is an association that is dedicated to the promotion of Open Design, based in Caldas da Rainha. From what we got it was the first time they talked to practioners about the field of graphic design. We talked about our work with the Libre Graphics magazine, the Kit Gráfica Livre, the From Stone to Spaceship workshop and why free software is about much more than saving money.
In my last multirotor themed entry I gave an insight into the magical world of flying cameras. I also gave a bit of a promise to write about the open source flight controllers that are out there. Here’s a few that I had the luck laying my hands on. We’ll start with some acro FCs, with a very differt purpose to the proprietary NAZA I started on. These are meant for fast and acrobatic flying, not for flying your expensive cameras on a stabilized gimbal. Keep in mind, I’m still fairly inexperienced so I don’t want to go into specifics and provide my settings just yet.
The best thing to be said about CC3D is that while being aimed at acro pilots, it’s relatively newbie friendly. The software is fairly straight forward. Getting the QT app built, set up the radio, tune motors and tweak gains is not going to make your eyes roll in the same way APM’s ground station would (more on that in a future post, maybe). The defaults are reasonable and help you achieve a maiden flight rather than a maiden crash. Updating to the latest firmware over the air is seamless.
Large number of receivers and connection methods is supported. Not only the classic PWM, or the more reasonable “one cable” CPPM method, but even Futaba proprietary SBUS can be used with CC3D. I’ve flown it with Futaba 8J, 14SG and even the Phantom radio (I actually quite like the compact receiver and the sticks on the TX feel good. Maybe it’s just that it’s something I’ve started on). As you’re gonna be flying proximity mostly, the range is not an issue, unless you’re dealing with external interference where a more robust frequency hopping radio would be safer. Without a GPS “break” or even a barometer, losing signal for even a second is fatal. It’s extremely nasty to get a perfect 5.8 video of your unresponsive quad plumetting to the ground :)
Overall a great board and software, and with so much competition, the board price has come down considerably recently. You can get non-genuine boards for around EUR20-25 on ebay. You can learn more about CC3D on openpilot website
Sounding very similar to the popular DJI flight controller, this open board is built around the 32-bit STM32 processor. Theoretically it could be used to fly a bit larger kites with features like GPS hold. You’re not limited to the popular quad or hexa setups with it either, you can go really custom with defining your own motor mix. But you’d be stepping in the realm of only a few and I don’t think I’d trust my camera equipment to a platform that hasn’t been so extensively tested.
Initially I didn’t manage to get the cheap acro variant ideal for the minis, so I got the ‘bells & whistles’ edition, only missing the GPS module. The mag compass and air pressure barometer is already on the board, even though I found no use for altitude hold (BARO). You’ll still going to worry about momentum and wind so reaching for those goggles mid flight is still not going to be any less difficult than just having it stabilized.
If you don’t count some youtube videos, there’s not a lot of handholding for the naze32. People assume you have prior experience with similar FCs. There are multiple choices of configuration tools, but I went for the most straight forward one — a Google Chrome/Chromium Baseflight app. No compiling necessary. It’s quite bare bones, which I liked a lot. Reasonably styled few aligned boxes and CLI is way easier to navigate than the non-searchable table with bubblegum styling than what APM provides for example.
One advanced technique that caught my eye, as the typical process is super flimsy and tedious, is ESC calibration. To set the full range of speeds based on your radio, you usually need to make sure to provide power to the RX, and setting the top and bottom throttle leves to each esc. With this FC, you can actually set the throttle levels from the CLI, calibrating all ESCs at the same time. Very clever and super useful.
Another great feature is that you can have up to three setting profiles, depending on the load, wind conditions and the style you’re going for. Typically when flying proximity, between trees and under park benches, you want very responsive controls at the expense of fluid movement. On the other hand if you plan on going up and fast and pretend to be a plane (or a bird), you really need to have that fluid non-jittery movement. It’s not a setting you change mid-flight, using up a channel, but rather something you choose before arming.
To do it, you hold throttle down and yaw to the left and with the elevator/aileron stick you choose the mode. Left is for preset1, up is for preset 2 and right is for preset 3. Going down with the pitch will recalibrate the IMU. It’s good to solder on a buzzer that will help you find a lost craft when you trigger it with a spare channel (it can beep on low voltage too). The same buzzer will beep for selecting profiles as well.
As for actual flying characteristics, the raw rate mode, which is a little tricky to master (and I still have trouble flying 3rd person with it), is very solid. It feels like a lot larger craft, very stable. There’s also quite a feat in the form of HORI mode, where you get a stabilized flight (kite levels itself when you don’t provide controls), but no limit on the angle, so you’re still free to do flips. I can’t say I’ve masted PID tuning to really get the kind of control over the aircraft I would want. Regardless of tweaking the control characteristics, you won’t get a nice fluid video flying HORI or ANGLE mode, as the self leveling will always do a little jitter to compensate for wind or inaccurate gyro readings which seems to not be there when flying rate. Stabilizing the footage in post gets rid of it mostly, but not perfectly:<iframe allowfullscreen="allowfullscreen" frameborder="0" height="500" src="http://www.youtube.com/embed/kVCTv2AlwTo?list=UUvteAidIfQtf2FkUzxr8QVg" width="100%"> Minihquad in Deutschland</iframe>
You can get the plain acro version for about EUR30 which is an incredible value for a solid FC like this. I have a lot of practice ahead to truly get to that fluid fast plane-like flight that drew me into these miniquads. Check some of these masters below:
APM and Sparky next time. Or perhaps you’d be more interested in the video link instead first? Let me know in the comments.
Update: Turns out NAZE32 supports many serial protocols apart form CPPM, such as Futaba SBUS and Graupner SUMD.
Classic video of CT instructor Thomas Phinney discussing the design of pan-european OpenType Fonts
Take a look behind the scenes at a London-based type-design studio crafting typographic systems for major clients using several different languages and writing systems. Read more at http://creativepro.com/article/bruno-maag-interview-designing-type-for-other-languages-and-alphabets
Video! Cooper-Hewitt: Wicked Problems in Type Design
This blog post is mostly about showing some photos I took, but I may as well give a brief summary from my point of view.
Had a good time in Strasbourg this week. Hacked a bit on Adwaita with Lapo, who has fearlessly been sanding the rough parts after the major refactoring. Jim Hall uncovered the details of his recent usability testing of GNOME, so while we video chatted before, it was nice to meet him in person. Watched Christian uncover his bold plans to focus on Builder full time which is both awesome and sad. Watched Jasper come out with the truth about his love for Windows and Federico’s secret to getting around fast. Uncovered how Benjamin is not getting more aerodynamic (ie fat) like me. Enjoyed a lot of great food (surprisingly had crêpes only once).
In a classic move I ran out of time in my lightning talk on multirotors, so I’ll have to cover the topic of free software flight controllers in a future blog post. I managed to miss a good number of talks I intended to see, which is quite a feat, considering the average price of beer in the old town. Had a good time hanging out with folks which is so rare to me.
During the BOFs on Wednesday I sat down with the Boxes folks, discussing some new designs. Sad that it was only few brief moments I managed to talk to Bastian about our Blender workflows. Unfortunately the Brno folks from whom I stole a spot in the car had to get back on Thursday so I missed the Thursday and Friday BOFs as well.
Despite the weather I enjoyed the second last GUADEC. Thanks for making it awesome again. See you in the next last one in Gothenburg.
Carol Twombly checking stuff
CT alumni and typography expert Jeff Barlow is holding a 1-day typography workshop in Seattle in a couple of week, on Thursday 10th July:
A hands-on workshop using pen, paper, and then computers to lead students to use typography for greater expressive quality and readability.
Check it out!
New tumblr, typedesignersatwork, is very good.
Franck Jalleau checking stuff
Street lettering images from a walk near Our Lady of Immaculate Conception Church and Archbishop’s House in Panjim, Goa. See all at Flickr.
&subset=all. Some people are less concerned with shaving off a few milliseconds and more with "will this actually work in my target language?".
Now that the controversial 3.12 tab design has been validated by Apple, we’re ready to tackle new challenges with the widgetry™.
Adwaita has grown into a fairly complex theme. We make sure unfocused windows are less eye-grabbing (flat). We provide a less light-polluting variant for visually-heavy content apps (Adwaita:dark). And last but not least we provide a specific wigdet style for overlay controls (OSD). All this complexity has made Adwaita quite a challenge to maintain and evolve. Since we were to relocate Adwaita directly into gtk+, we had to bite the bullet and perform quite a surgery on it.
There’s a number of improvements we aimed to achieve. Limiting the number of distinct colors and making most colors derived makes it easier to adjust the overall feel of the theme and I’m sure 3rd party themers will enjoy this too. Not relying on image assets for majority of the drawing makes the workflow much more flexible as well. Many of the small graphical elements now make use of the icon theme assets so these remain recolorable based on the context, similar to how text is treated.
Benjamin has been working hard to move the theme closer to the familiar CSS box model, further minimizing the reliance on odd property hacks and engines (Adwaita no longer makes use of any engine drawing).
We still rely on some image assets, but even that is much more manageable with SASS.
Anything gtk related never happens without the giant help from Matthias, Cosimo and Benjamin, but I have to give extra credits to Lapo Calamandrei, without whom these dark caverns would be impossible for me to enter. Another major piece that I’m grateful for living right inside the toolkit, ready to be brought up any time, is the awesome inspector. Really happy to see it mature and evolve.
Wow, Philip. OPW is a detriment to GNOME development in the same way an espresso or electronic music is. You may not appreciate its catalyst effect to great contributions, but blaming it for being one of the reasons why our developer story is sub optimal is very disrespecting to the people responsible for the program.
I am amused when poor developer workflow immediately becomes “gnome terminal lacks transparency” (and it being the design team’s decision), but reading this sort of lunacy on Planet GNOME is sad.
Tom Creighton attended the recent Crafting Type Toronto and posted his result up on Dribbble:
started a legit typeface this past weekend after getting knowledge-bombed at a Crafting Type workshop. Pretty happy with how it’s coming together.
Great work Tom!