Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 18 uur 12 min geleden

Frédéric Harper: The Day I Wanted to Kill Myself

ma, 18/04/2016 - 02:54
My semicolon tattoo

My semicolon tattoo

A little more than a year ago, my life was perfect. At least, from my own point of view. I was engaged to the most formidable woman I ever knew and we were living in our beautiful spacious condominium with our kids, our three cats. People were paying me very well to share my passion about technology and travel all over the world to help developers succeed with their projects. My friends and family were an important part of my life and even if I wasn’t the healthiest man on earth, I had no real health issues. I was happy and I couldn’t ask for more… Until my world collapsed.

I was 4500 kilometers away from home when I learned that the woman of my life, the one I spent one fourth of my young existence with, was leaving me. That was, the end of my world! Like if it wasn’t enough to lose the person you share your life with, some people I considered friends ran away from me: sad Fred is no fun, and obviously, when there is a separation, people feel the needs to “take a side”. Right before, I realized that the company I was working for, wasn’t the right one for me, so I decided to resign: I wasn’t able to deliver as I should taking this in the equation with everything else. Of course, I had no savings and it’s at that exact moment that we had water damage in our building and that I had to pay out a couple of thousands for the renovation. During that period, I sank deeply and very quickly: someone calls Depression knocked at my door.

For months, I was going deeper in the rabbit hole. Everything was hard to achieve, and uninteresting: even taking my shower was a real exploit. I was staying home, doing nothing except eating shitty food, getting weight and watching Netflix. I’ve always considered myself a social beast, but even just seeing my best friend was painful and unpleasant. I didn’t want to talk to people at all. I didn’t want to see people. I didn’t need help even if I felt I was a failure. My life was a failure. During that period, my “happiest” moments were when I was at a bar, drinking: alcohol was making me numb, making me forget that I was swimming in the dark all day long. Obviously, that tasty nectar called beer wasn’t helping me at all: it was taking me deeper than I was and as any stupid human, I was trying to get back my love, in the most ineffective way ever, to stay polite with myself. On top of that, even with good will, everyone was giving me shitty advices (side note: in that situation, the only thing you should do is being there for the other – you don’t know what the person is going thru and please, don’t give advices, just be there). That piece of shit that I was seeing in the mirror couldn’t have been me: I was strong. I’ve always done everything in my life to be happy: why I was not able to make the necessary changes to get back on my feet? Something was pulling me to the bottom and was putting weight on my shoulder. I wasn’t happy anymore, my life wasn’t valuable anymore. Maybe the solution was to kill myself?

Seriously, why live in a world where the woman I wanted to spend the rest of my life, the woman who wanted to spend the rest of her life with my own person, was running away from me? Why live in a world where people were spitting on me, not literally, in the lovely world that is social media? Why live in a world where the job I thought I was born for was maybe not made for me? You know that thing call the impostor syndrome? I wasn’t happy and I wasn’t seeing the light at the end of the tunnel. I had no more strength left. I didn’t have a proper night of sleep for weeks and no healthy meal since, forever. I don’t even talk about exercise… I was practically dead already, so one night, I drank like never before, and had the marvellous idea to nearly harass my former fiancé: I wanted her back. She closed her phone, it was the end: I decided it was the end. I was an asshole. I had enough. I wasn’t able to take more of that shit that is life. Fortunately, I blacked out, being truly intoxicated, before doing anything irreparable… until the cops knocked at my door. They were there to check if I was still alive. Two cops, at my door, wanted to see if I was alive. Can you imagine? I’m pretty sure you can’t. I was shaking and nearly crying: they were ready to smash my door if I wasn’t answering them in the second after I did. I reached a point where people who still cared about me were worried enough to call the police. Can you imagine again? Worrying the people you love so much that they need to take drastic actions like this? I was terrified. I. Was. Terrified. Not about the cops, but about me… I was at a breaking point! Fuck…

At that exact moment, I decided I needed to try to take care of myself. I started to see a psychologist twice a week. My doctor prescribed me antidepressants and pills to help me sleep a bit. Until now, I didn’t take any medicine for my severe deficit attention disorder (ADD – ADHD, with hyperactivity, in my case) that was diagnosed years ago, but I asked my doctor to add this to the cocktails of pills she was giving me. I also forced myself to see my close friends and I stopped taking anything containing alcohol. It was a complete turn around: anything that was helping me to see some light out of that terrible time of my life was part of my plan. Actually, I didn’t had any plan, I just wanted to run away from that scariest part of me. I even started to write a personal diary every time I had a difficult thought in my mind, which was more than once daily. It wasn’t easy. I wasn’t happy, but I was scared. I was scared to get back to that moment when the only plausible idea was to end my life. The frightening was bigger than the sadness, trust me. Baby steps were made to go forward. It was, and still is the biggest challenge I ever had in my life.

One evening, I was with my best friend at a Jean Leloup show: for a small moment, first time since months, I was having fun. I was smiling! And I started to cry… I realized that if I had killed myself, I wouldn’t be able to be there, with a man who is loving me as a friend for eighteen years and supported me like no one during that difficult time. I wouldn’t have been able to be there, singing and dancing on the music I love so much… At that exact moment, I knew I was starting to slowly get back on my feet. I knew that it wasn’t only the right thing to do, it was the thing to do. Thanks to my parents, my friends and the health professionals, I was finally feeling like my life was improving. It was a work in progress, but I was going in the right direction.

Still today, life isn’t easy. Life is continuing to throw rocks at me, like my mother getting a diagnostic of Alzheimer and this week, a cancer. I’m still trying to fix parts of my life, trying to find myself, but I can smile now, most of the time. It’s a constant battle, but I now know it’s worth it. Anyhow, I have mental illness and I’m not ashamed anymore of it: I’m not ashamed anymore of what happened! I’m putting all efforts I can to make my life better. Again, it’s not easy, but small steps at a time, I’m getting better. Since, there is a semicolon tattoo on my wrist (picture above) to remember me that life is precious. That my life is precious. I could’ve ended my life, like an author ending a sentence sentence with a coma, but I chose not to: my story isn’t over…

P.S.: If you have suicide ideas or feels like you are going thru what I’ve lived, please call a friend. If you don’t want or can’t, call Suicide Action Montreal at 514-723-4000 or check the hotline number in your country. You deserve better. You deserve to live!

Categorieën: Mozilla-nl planet

The Servo Blog: This Week In Servo 60

ma, 18/04/2016 - 02:30

In the last week, we landed 120 PRs in the Servo organization’s repositories.

We have cancelled the weekly meeting. In order to ensure we still make the same or more information available, This Week in Servo will be extended to include planning/status information, call out any other ad-hoc meetings that occur during the week, and mention any notable threads on the mailing list.

Planning and Status

Our overall roadmap and quarterly goals are available online.

This week’s status updates are here.

Notable Additions
  • KiChjang implemented the CORS Preflight Fetch algorithm
  • mbrubeck fixed some margin collapse code in layout
  • larsberg added a Windows buildbot
  • notriddle avoided propagation of floated layout elements into or out of absolutely positioned ones
  • mrobinson removed the concept of stacking levels for display lists
  • edunham packaged up our tidy script and published it to PyPi
  • ajeffrey added panic messages to failures
  • fitzgen made the profiling data take the stdout lock to avoid jumbled output
  • manish upgraded the Rust compiler to 2016-04-12
  • bholley avoided in-memory movement of Gecko style structs
  • manish reduced the number of threads Servo uses just for panic handling
  • izgzhen implemented the first parts of window.performance.timing
  • danlrobertson implemented flexbox reordering
  • pcwalton disallowed margins from collapsing through block formatting contexts in layout
  • kaksmet fixed sandboxing on OSX
  • frewsxcv implemented rowIndex and sectionRowIndex on <tr>
  • nox continued the SpiderMonkey update, ./mach test-css now passes on the smup branch
  • yoava333 corrected a Windows panic when resolving file URLs
  • jack toggled more SpiderMonkey options that improve performance on JS benchmarks
  • dzbarsky enabled a huge swath of WebGL conformance tests after a heroic struggle
  • DDEFISHER implemented support for responding to basic HTTP authorization requests
  • perlun extracted the monolithic parts of our Mako-based code generation into separate Python files
New Contributors Get Involved

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!


The University of Szeged team continues their awesome work on WebBluetooth support, with a neat demo video!

Meetings and Mailing List

Last week, we had a meeting with the Firefox developer tools team discussing protocol plans, Devtools.html, architectural design, and some potential future features brainstorming.

Categorieën: Mozilla-nl planet

Karl Dubost: [worklog] Ganesh, remover of obstacles

ma, 18/04/2016 - 01:01

Earthquake in Kumamoto (Green circle is where I live). For people away from Japan, it always sounds like a scary thing. This one was large but still Japan is a big series of islands and where I live was far from the Earthquake. Or if you want a comparison it's a bit like people in Japan who would be worried for people in New-York because of an earthquake in Miami, or for people in Oslo because of an earthquake in Athens. Time to remove any obstacles, so Ganesh.

Tune of the week: Deva Shree Ganesha - Agneepath.

Webcompat Life

Progress this week:

Today: 2016-04-18T07:52:17.560261 374 open issues ---------------------- needsinfo 3 needsdiagnosis 126 needscontact 25 contactready 95 sitewait 122 ----------------------

You are welcome to participate

Preparing Londong agenda.

After reducing the incoming bug to nearly 0 every day in the previous weeks, I have now reduced the needscontact around 25 issues. Most of the remaining are for Microsoft, Opera, Firefox OS community to deal with. My next target is the contactready ones around 100 issues.

Posted my git/github workflow.

Webcompat issues

(a selection of some of the bugs worked on this week).

Webcompat development They are invisible

Some people in the Mozilla community are publishing on Medium, aka their content will disappear one day when you know Medium will be bought or just sunset. It's a bit sad. Their content is also most of the time not syndicated elsewhere.

Reading List
  • A must-watch video about the Web and understands why it is cool to develop for the Web. All along the talk I was thinking: When native will finally catch up with the Web.
  • A debugging thought process
Follow Your Nose TODO
  • Document how to write tests on using test fixtures.
  • ToWrite: rounding numbers in CSS for width
  • ToWrite: Amazon prefetching resources with <object> for Firefox only.


Categorieën: Mozilla-nl planet

Armen Zambrano: Project definition: Give Treeherder the ability to schedule TaskCluster jobs

zo, 17/04/2016 - 18:01
This is a project definition that I put up for GSoC 2016. This helps students to get started researching the project.

The main things I give in here are:

  • Background
    • Where we came from, where we are and we are heading towards
  • Goal
    • Use case for developers
  • Breakdown of components
    • Rather than all aspects being mixed and not logically separate

NOTE: This project has few parts that have risks and could change the implementation. It depends on close collaboration with dustin.

Mentor: armenzg IRC:   #ateam channelGive Treeherder the ability to schedule TaskCluster jobsThis work will enable "adding new jobs" on Treeherder to work with pushes lacking TaskCluster jobs (our new continuous integration system). Read this blog post to know how the project was built for Buildbot jobs (our old continous integration system).
The main work for this project is tracked in bug 1254325.
In order for this to work we need the following pieces:A - Generate data source with all possible tasksB - Teach Treeherder to use the artifact
  • This will require close collaboration with Treeherder engineers
  • This work can be done locally with a Treeherder instance
  • It can also be deployed to the “staging” version of Treeherder to do tests
  • Alternative mentors for this section is: camd
C - Teach pulse_actions to listen for requests from Treeherder
  • pulse_actions is a pulse listener of Treeherder actions
  • You can see pulse_actions’ workflow in here
  • Once part B is completed, we will be able to listen for messages requesting certain TaskCluster tasks to be scheduled and we will schedule those tasks on behalf of the user
  • RISK: Depending if the TaskCluster actions project is completed on time, we might instead make POST requests to an API

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Armen Zambrano: Project definition: SETA re-write

zo, 17/04/2016 - 17:54
As an attempt to attract candidates to GSoC I wanted to make sure that the possible projects were achievable rather than lead them on a path of pain and struggle. It also helps me picture the order on which it makes more sense to accomplish.

It was also a good exercise for students to have to read and ask questions about what was not clear and give lots to read about the project.

I want to share this and another project definition in case it is useful for others.

We want to rewrite SETA to be easy to deploy through Heroku and to support TaskCluster (our new continuous integration system) [0].
Please read carefully this document before starting to ask questions. There is high interest in this project and it is burdensome to have to re-explain it to every new prospective student.
Main mentor: armenzg (#ateam)Co-mentor: jmaher (#ateam)
Please read jmaher’s blog post carefully [1] before reading anymore.
Now that you have read jmaher’s blog post, I will briefly go into some specifics.SETA reduces the number of jobs that get scheduled on a developer’s push.A job is every single letter you see on Treeherder. For every developer’s push there is a number of these jobs scheduled.On every push, Buildbot [6] decides what to schedule depending on the data that it fetched from SETA [7].
The purpose of this project is two-fold:
  1. Write SETA as an independent project that is:
    1. maintainable
    2. more reliable
    3. automatically deployed through Heroku app
  2. Support TaskCluster, our new CI (continuous integration system)

NOTE: The current code of SETA [2] lives within a repository called ouija.
Ouija does the following for SETA:
  1. It has a cronjob which kicks in every 12 hours to scrape information about jobs from every push
  2. It takes the information about jobs (which it grabs from Treeherder) into a database

SETA then goes a queries the database to determine which jobs should be scheduled. SETA chooses jobs that are good at reporting issues introduced by developers. SETA has its own set of tables and adds the data there for quick reference.
Involved pieces for this project:
  1. Get familiar with deploying apps and using databases in Heroku
  2. Host SETA in Heroku instead of
  3. Teach SETA about TaskCluster
  4. Change the gecko decision task to reliably use SETA [5][6]
    1. If the SETA service is not available we should fall back to run all tasks/jobs
  5. Document how SETA works and auto-deployments of docs and Heroku
    1. Write automatically generated documentation
    2. Add auto-deployments to Heroku and readthedocs
  6. Add tests for SETA
    1. Add tox/travis support for tests and flake8
  7. Re-write SETA using ActiveData [3] instead of using data collected by Ouija
  8. Make the current CI (Buildbot) use the new SETA Heroku service
  9. Create SETA data for per test information instead of per job information (stretch goal)
    1. On Treeherder we have jobs that contain tests
    2. Tests re-order between those different chunks
    3. We want to run jobs at a per-directory level or per-manifest
  10. Add priorities into SETA data (stretch goal)
    1. Priority 1 gets every time
    2. Priority 2 gets triggered on Y push

[0][1][2][3][4][5][6] testing/taskcluster/[7][8]

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Frédéric Wang: OpenType MATH in HarfBuzz

za, 16/04/2016 - 23:23


  • Work is in progress to add OpenType MATH support in HarfBuzz and will be instrumental for many math rendering engines relying on that library, including browsers.

  • For stretchy operators, an efficient way to determine the required number of glyphs and their overlaps has been implemented and is described here.

In the context of Igalia browser team effort to implement MathML support using TeX rules and OpenType features, I have started implementation of OpenType MATH support in HarfBuzz. This table from the OpenType standard is made of three subtables:

  • The MathConstants table, which contains layout constants. For example, the thickness of the fraction bar of <semantics>ab<annotation encoding="application/x-tex">\frac{a}{b}</annotation></semantics>.

  • The MathGlyphInfo table, which contains glyph properties. For instance, the italic correction indicating how slanted an integral is e.g. to properly place the subscript in <semantics>∫D<annotation encoding="application/x-tex">\displaystyle\displaystyle\int_{D}</annotation></semantics>.

  • The MathVariants table, which provides larger size variants for a base glyph or data to build a glyph assembly. For example, either a larger parenthesis or a assembly of U+239B, U+239C, U+239D to write something like:

      <semantics>(abcdefgh<annotation encoding="application/x-tex">\left(\frac{\frac{\frac{a}{b}}{\frac{c}{d}}}{\frac{\frac{e}{f}}{\frac{g}{h}}}\right.</annotation></semantics>  

Code to parse this table was added to Gecko and WebKit two years ago. The existing code to build glyph assembly in these Web engines was adapted to use the MathVariants data instead of only private tables. However, as we will see below the MathVariants data to build glyph assembly is more general, with arbitrary number of glyphs or with additional constraints on glyph overlaps. Also there are various fallback mechanisms for old fonts and other bugs that I think we could get rid of when we move to OpenType MATH fonts only.

In order to add MathML support in Blink, it is very easy to import the OpenType MATH parsing code from WebKit. However, after discussions with some Google developers, it seems that the best option is to directly add support for this table in HarfBuzz. Since this library is used by Gecko, by WebKit (at least the GTK port) and by many other applications such as Servo, XeTeX or LibreOffice it make senses to share the implementation to improve math rendering everywhere.

The idea for HarfBuzz is to add an API to

  1. 1.

    Expose data from the MathConstants and MathGlyphInfo.

  2. 2.

    Shape stretchy operators to some target size with the help of the MathVariants.

It is then up to a higher-level math rendering engine (e.g. TeX or MathML rendering engines) to beautifully display mathematical formulas using this API. The design choice for exposing MathConstants and MathGlyphInfo is almost obvious from the reading of the MATH table specification. The choice for the shaping API is a bit more complex and discussions is still in progress. For example because we want to accept stretching after glyph-level mirroring (e.g. to draw RTL clockwise integrals) we should accept any glyph and not just an input Unicode strings as it is the case for other HarfBuzz shaping functions. This shaping also depends on a stretching direction (horizontal/vertical) or on a target size (and Gecko even currently has various ways to approximate that target size). Finally, we should also have a way to expose italic correction for a glyph assembly or to approximate preferred width for Web rendering engines.

As I mentioned at the beginning, the data and algorithm to build glyph assembly is the most complex part of the OpenType MATH and deserves a special interest. The idea is that you have a list of <semantics>n≥1<annotation encoding="application/x-tex">n\geq 1</annotation></semantics> glyphs available to build the assembly. For each <semantics>0≤i≤n-1<annotation encoding="application/x-tex">0\leq i\leq n-1</annotation></semantics>, the glyph <semantics>gi<annotation encoding="application/x-tex">g_{i}</annotation></semantics> has advance <semantics>ai<annotation encoding="application/x-tex">a_{i}</annotation></semantics> in the stretch direction. Each <semantics>gi<annotation encoding="application/x-tex">g_{i}</annotation></semantics> has straight connector part at its start (of length <semantics>si<annotation encoding="application/x-tex">s_{i}</annotation></semantics>) and at its end (of length <semantics>ei<annotation encoding="application/x-tex">e_{i}</annotation></semantics>) so that we can align the glyphs on the stretch axis and glue them together. Also, some of the glyphs are “extenders” which means that they can be repeated 0, 1 or more times to make the assembly as large as possible. Finally, the end/start connectors of consecutive glyphs must overlap by at least a fixed value <semantics>omin<annotation encoding="application/x-tex">o_{\mathrm{min}}</annotation></semantics> to avoid gaps at some resolutions but of course without exceeding the length of the corresponding connectors. This gives some flexibility to adjust the size of the assembly and get closer to the target size <semantics>t<annotation encoding="application/x-tex">t</annotation></semantics>.

<foreignObject color="#0000FF" width="16.19" height="100%">

<semantics>gi<annotation encoding="application/x-tex">g_{i}</annotation></semantics>

</foreignObject><foreignObject color="#0000FF" width="16.19" height="100%">

<semantics>si<annotation encoding="application/x-tex">s_{i}</annotation></semantics>

</foreignObject><foreignObject color="#0000FF" width="16.19" height="100%">

<semantics>ei<annotation encoding="application/x-tex">e_{i}</annotation></semantics>

</foreignObject><foreignObject color="#0000FF" width="16.19" height="100%">

<semantics>ai<annotation encoding="application/x-tex">a_{i}</annotation></semantics>

</foreignObject><foreignObject color="#FF0000" width="27.81" height="100%">

<semantics>gi+1<annotation encoding="application/x-tex">g_{i+1}</annotation></semantics>

</foreignObject><foreignObject color="#FF0000" width="27.81" height="100%">

<semantics>si+1<annotation encoding="application/x-tex">s_{i+1}</annotation></semantics>

</foreignObject><foreignObject color="#FF0000" width="27.81" height="100%">

<semantics>ei+1<annotation encoding="application/x-tex">e_{i+1}</annotation></semantics>

</foreignObject><foreignObject color="#FF0000" width="27.81" height="100%">

<semantics>ai+1<annotation encoding="application/x-tex">a_{i+1}</annotation></semantics>

</foreignObject><foreignObject color="#000000" width="39.43" height="100%">

<semantics>oi,i+1<annotation encoding="application/x-tex">o_{i,i+1}</annotation></semantics>

</foreignObject> Figure 0.1: Two adjacent glyphs in an assembly

To ensure that the width/height is distributed equally and the symmetry of the shape is preserved, the MATH table specification suggests the following iterative algorithm to determine the number of extenders and the connector overlaps to reach a minimal target size <semantics>t<annotation encoding="application/x-tex">t</annotation></semantics>:

  1. 1.

    Assemble all parts by overlapping connectors by maximum amount, and removing all extenders. This gives the smallest possible result.

  2. 2.

    Determine how much extra width/height can be distributed into all connections between neighboring parts. If that is enough to achieve the size goal, extend each connection equally by changing overlaps of connectors to finish the job.

  3. 3.

    If all connections have been extended to minimum overlap and further growth is needed, add one of each extender, and repeat the process from the first step.

We note that at each step, each extender is repeated the same number of times <semantics>r≥0<annotation encoding="application/x-tex">r\geq 0</annotation></semantics>. So if <semantics>IExt<annotation encoding="application/x-tex">I_{\mathrm{Ext}}</annotation></semantics> (respectively <semantics>INonExt<annotation encoding="application/x-tex">I_{\mathrm{NonExt}}</annotation></semantics>) is the set of indices <semantics>0≤i≤n-1<annotation encoding="application/x-tex">0\leq i\leq n-1</annotation></semantics> such that <semantics>gi<annotation encoding="application/x-tex">g_{i}</annotation></semantics> is an extender (respectively is not an extender) we have <semantics>ri=r<annotation encoding="application/x-tex">r_{i}=r</annotation></semantics> (respectively <semantics>ri=1<annotation encoding="application/x-tex">r_{i}=1</annotation></semantics>). The size we can reach at step <semantics>r<annotation encoding="application/x-tex">r</annotation></semantics> is at most the one obtained with the minimal connector overlap <semantics>omin<annotation encoding="application/x-tex">o_{\mathrm{min}}</annotation></semantics> that is

<semantics>∑i=0N-1(∑j=1riai-omin)+omin=(∑i∈INonExtai-omin)+(∑i∈IExtr⁢(ai-omin))+omin<annotation encoding="application/x-tex">\sum_{i=0}^{N-1}\left(\sum_{j=1}^{r_{i}}{a_{i}-o_{\mathrm{min}}}\right)+o_{% \mathrm{min}}=\left(\sum_{i\in I_{\mathrm{NonExt}}}{a_{i}-o_{\mathrm{min}}}% \right)+\left(\sum_{i\in I_{\mathrm{Ext}}}r{(a_{i}-o_{\mathrm{min}})}\right)+o% _{\mathrm{min}}</annotation></semantics>

We let <semantics>NExt=|IExt|<annotation encoding="application/x-tex">N_{\mathrm{Ext}}={|I_{\mathrm{Ext}}|}</annotation></semantics> and <semantics>NNonExt=|INonExt|<annotation encoding="application/x-tex">N_{\mathrm{NonExt}}={|I_{\mathrm{NonExt}}|}</annotation></semantics> be the number of extenders and non-extenders. We also let <semantics>SExt=∑i∈IExtai<annotation encoding="application/x-tex">S_{\mathrm{Ext}}=\sum_{i\in I_{\mathrm{Ext}}}a_{i}</annotation></semantics> and <semantics>SNonExt=∑i∈INonExtai<annotation encoding="application/x-tex">S_{\mathrm{NonExt}}=\sum_{i\in I_{\mathrm{NonExt}}}a_{i}</annotation></semantics> be the sum of advances for extenders and non-extenders. If we want the advance of the glyph assembly to reach the minimal size <semantics>t<annotation encoding="application/x-tex">t</annotation></semantics> then

  <semantics>SNonExt-omin⁢(NNonExt-1)+r⁢(SExt-omin⁢NExt)≥t<annotation encoding="application/x-tex">{S_{\mathrm{NonExt}}-o_{\mathrm{min}}\left(N_{\mathrm{NonExt}}-1\right)}+{r% \left(S_{\mathrm{Ext}}-o_{\mathrm{min}}N_{\mathrm{Ext}}\right)}\geq t</annotation></semantics>  

We can assume <semantics>SExt-omin⁢NExt>0<annotation encoding="application/x-tex">S_{\mathrm{Ext}}-o_{\mathrm{min}}N_{\mathrm{Ext}}>0</annotation></semantics> or otherwise we would have the extreme case where the overlap takes at least the full advance of each extender. Then we obtain

  <semantics>r≥rmin=max⁡(0,⌈t-SNonExt+omin⁢(NNonExt-1)SExt-omin⁢NExt⌉)<annotation encoding="application/x-tex">r\geq r_{\mathrm{min}}=\max\left(0,\left\lceil\frac{t-{S_{\mathrm{NonExt}}+o_{% \mathrm{min}}\left(N_{\mathrm{NonExt}}-1\right)}}{S_{\mathrm{Ext}}-o_{\mathrm{% min}}N_{\mathrm{Ext}}}\right\rceil\right)</annotation></semantics>  

This provides a first simplification of the algorithm sketched in the MATH table specification: Directly start iteration at step <semantics>rmin<annotation encoding="application/x-tex">r_{\mathrm{min}}</annotation></semantics>. Note that at each step we start at possibly different maximum overlaps and decrease all of them by a same value. It is not clear what to do when one of the overlap reaches <semantics>omin<annotation encoding="application/x-tex">o_{\mathrm{min}}</annotation></semantics> while others can still be decreased. However, the sketched algorithm says all the connectors should reach minimum overlap before the next increment of <semantics>r<annotation encoding="application/x-tex">r</annotation></semantics>, which means the target size will indeed be reached at step <semantics>rmin<annotation encoding="application/x-tex">r_{\mathrm{min}}</annotation></semantics>.

One possible interpretation is to stop overlap decreasing for the adjacent connectors that reached minimum overlap and to continue uniform decreasing for the others until all the connectors reach minimum overlap. In that case we may lose equal distribution or symmetry. In practice, this should probably not matter much. So we propose instead the dual option which should behave more or less the same in most cases: Start with all overlaps set to <semantics>omin<annotation encoding="application/x-tex">o_{\mathrm{min}}</annotation></semantics> and increase them evenly to reach a same value <semantics>o<annotation encoding="application/x-tex">o</annotation></semantics>. By the same reasoning as above we want the inequality

  <semantics>SNonExt-o⁢(NNonExt-1)+rmin⁢(SExt-o⁢NExt)≥t<annotation encoding="application/x-tex">{S_{\mathrm{NonExt}}-o\left(N_{\mathrm{NonExt}}-1\right)}+{r_{\mathrm{min}}% \left(S_{\mathrm{Ext}}-oN_{\mathrm{Ext}}\right)}\geq t</annotation></semantics>  

which can be rewritten

  <semantics>SNonExt+rmin⁢SExt-o⁢(NNonExt+rmin⁢NExt-1)≥t<annotation encoding="application/x-tex">S_{\mathrm{NonExt}}+r_{\mathrm{min}}S_{\mathrm{Ext}}-{o\left(N_{\mathrm{NonExt% }}+{r_{\mathrm{min}}N_{\mathrm{Ext}}}-1\right)}\geq t</annotation></semantics>  

We note that <semantics>N=NNonExt+rmin⁢NExt<annotation encoding="application/x-tex">N=N_{\mathrm{NonExt}}+{r_{\mathrm{min}}N_{\mathrm{Ext}}}</annotation></semantics> is just the exact number of glyphs used in the assembly. If there is only a single glyph, then the overlap value is irrelevant so we can assume <semantics>NNonExt+r⁢NExt-1=N-1≥1<annotation encoding="application/x-tex">N_{\mathrm{NonExt}}+{rN_{\mathrm{Ext}}}-1=N-1\geq 1</annotation></semantics>. This provides the greatest theorical value for the overlap <semantics>o<annotation encoding="application/x-tex">o</annotation></semantics>:

  <semantics>omin≤o≤omaxtheorical=SNonExt+rmin⁢SExt-tNNonExt+rmin⁢NExt-1<annotation encoding="application/x-tex">o_{\mathrm{min}}\leq o\leq o_{\mathrm{max}}^{\mathrm{theorical}}=\frac{S_{% \mathrm{NonExt}}+r_{\mathrm{min}}S_{\mathrm{Ext}}-t}{N_{\mathrm{NonExt}}+{r_{% \mathrm{min}}N_{\mathrm{Ext}}}-1}</annotation></semantics>  

Of course, we also have to take into account the limit imposed by the start and end connector lengths. So <semantics>omax<annotation encoding="application/x-tex">o_{\mathrm{max}}</annotation></semantics> must also be at most <semantics>min⁡(ei,si+1)<annotation encoding="application/x-tex">\min{(e_{i},s_{i+1})}</annotation></semantics> for <semantics>0≤i≤n-2<annotation encoding="application/x-tex">0\leq i\leq n-2</annotation></semantics>. But if <semantics>rmin≥2<annotation encoding="application/x-tex">r_{\mathrm{min}}\geq 2</annotation></semantics> then extender copies are connected and so <semantics>omax<annotation encoding="application/x-tex">o_{\mathrm{max}}</annotation></semantics> must also be at most <semantics>min⁡(ei,si)<annotation encoding="application/x-tex">\min{(e_{i},s_{i})}</annotation></semantics> for <semantics>i∈IExt<annotation encoding="application/x-tex">i\in I_{\mathrm{Ext}}</annotation></semantics>. To summarize, <semantics>omax<annotation encoding="application/x-tex">o_{\mathrm{max}}</annotation></semantics> is the minimum of <semantics>omaxtheorical<annotation encoding="application/x-tex">o_{\mathrm{max}}^{\mathrm{theorical}}</annotation></semantics>, of <semantics>ei<annotation encoding="application/x-tex">e_{i}</annotation></semantics> for <semantics>0≤i≤n-2<annotation encoding="application/x-tex">0\leq i\leq n-2</annotation></semantics>, of <semantics>si<annotation encoding="application/x-tex">s_{i}</annotation></semantics> <semantics>1≤i≤n-1<annotation encoding="application/x-tex">1\leq i\leq n-1</annotation></semantics> and possibly of <semantics>e0<annotation encoding="application/x-tex">e_{0}</annotation></semantics> (if <semantics>0∈IExt<annotation encoding="application/x-tex">0\in I_{\mathrm{Ext}}</annotation></semantics>) and of of <semantics>sn-1<annotation encoding="application/x-tex">s_{n-1}</annotation></semantics> (if <semantics>n-1∈IExt<annotation encoding="application/x-tex">{n-1}\in I_{\mathrm{Ext}}</annotation></semantics>).

With the algorithm described above <semantics>NExt<annotation encoding="application/x-tex">N_{\mathrm{Ext}}</annotation></semantics>, <semantics>NNonExt<annotation encoding="application/x-tex">N_{\mathrm{NonExt}}</annotation></semantics>, <semantics>SExt<annotation encoding="application/x-tex">S_{\mathrm{Ext}}</annotation></semantics>, <semantics>SNonExt<annotation encoding="application/x-tex">S_{\mathrm{NonExt}}</annotation></semantics> and <semantics>rmin<annotation encoding="application/x-tex">r_{\mathrm{min}}</annotation></semantics> and <semantics>omax<annotation encoding="application/x-tex">o_{\mathrm{max}}</annotation></semantics> can all be obtained using simple loops on the glyphs <semantics>gi<annotation encoding="application/x-tex">g_{i}</annotation></semantics> and so the complexity is <semantics>O⁢(n)<annotation encoding="application/x-tex">O(n)</annotation></semantics>. In practice <semantics>n<annotation encoding="application/x-tex">n</annotation></semantics> is small: For existing fonts, assemblies are made of at most three non-extenders and two extenders that is <semantics>n≤5<annotation encoding="application/x-tex">n\leq 5</annotation></semantics> (incidentally, Gecko and WebKit do not currently support larger values of <semantics>n<annotation encoding="application/x-tex">n</annotation></semantics>). This means that all the operations described above can be considered to have constant complexity. This is much better than a naive implementation of the iterative algorithm sketched in the OpenType MATH table specification which seems to require at worst

  <semantics>∑r=0rmin-1NNonExt+r⁢NExt=NNonExt⁢rmin+rmin⁢(rmin-1)2⁢NExt=O⁢(n×rmin2)<annotation encoding="application/x-tex">\sum_{r=0}^{r_{\mathrm{min}}-1}{N_{\mathrm{NonExt}}+rN_{\mathrm{Ext}}}=N_{% \mathrm{NonExt}}r_{\mathrm{min}}+\frac{r_{\mathrm{min}}\left(r_{\mathrm{min}}-% 1\right)}{2}N_{\mathrm{Ext}}={O(n\times r_{\mathrm{min}}^{2})}</annotation></semantics>  

and at least <semantics>Ω⁢(rmin)<annotation encoding="application/x-tex">\Omega(r_{\mathrm{min}})</annotation></semantics>.

One of issue is that the number of extender repetitions <semantics>rmin<annotation encoding="application/x-tex">r_{\mathrm{min}}</annotation></semantics> and the number of glyphs in the assembly <semantics>N<annotation encoding="application/x-tex">N</annotation></semantics> can become arbitrary large since the target size <semantics>t<annotation encoding="application/x-tex">t</annotation></semantics> can take large values e.g. if one writes \underbrace{\hspace{65535em}} in LaTeX. The improvement proposed here does not solve that issue since setting the coordinates of each glyph in the assembly and painting them require <semantics>Θ⁢(N)<annotation encoding="application/x-tex">\Theta(N)</annotation></semantics> operations as well as (in the case of HarfBuzz) a glyph buffer of size <semantics>N<annotation encoding="application/x-tex">N</annotation></semantics>. However, such large stretchy operators do not happen in real-life mathematical formulas. Hence to avoid possible hangs in Web engines a solution is to impose a maximum limit <semantics>Nmax<annotation encoding="application/x-tex">N_{\mathrm{max}}</annotation></semantics> for the number of glyph in the assembly so that the complexity is limited by the size of the DOM tree. Currently, the proposal for HarfBuzz is <semantics>Nmax=128<annotation encoding="application/x-tex">N_{\mathrm{max}}=128</annotation></semantics>. This means that if each assembly glyph is 1em large you won’t be able to draw stretchy operators of size more than 128em, which sounds a quite reasonable bound. With the above proposal, <semantics>rmin<annotation encoding="application/x-tex">r_{\mathrm{min}}</annotation></semantics> and so <semantics>N<annotation encoding="application/x-tex">N</annotation></semantics> can be determined very quickly and the cases <semantics>N≥Nmax<annotation encoding="application/x-tex">N\geq N_{\mathrm{max}}</annotation></semantics> rejected, so that we avoid losing time with such edge cases…

Finally, because in our proposal we use the same overlap <semantics>o<annotation encoding="application/x-tex">o</annotation></semantics> everywhere an alternative for HarfBuzz would be to set the output buffer size to <semantics>n<annotation encoding="application/x-tex">n</annotation></semantics> (i.e. ignore <semantics>r-1<annotation encoding="application/x-tex">r-1</annotation></semantics> copies of each extender and only keep the first one). This will leave gaps that the client can fix by repeating extenders as long as <semantics>o<annotation encoding="application/x-tex">o</annotation></semantics> is also provided. Then HarfBuzz math shaping can be done with a complexity in time and space of just <semantics>O⁢(n)<annotation encoding="application/x-tex">O(n)</annotation></semantics> and it will be up to the client to optimize or limit the painting of extenders for large values of <semantics>N<annotation encoding="application/x-tex">N</annotation></semantics>…

Categorieën: Mozilla-nl planet

Mark Finkle: Pitching Ideas – It’s Not About Perfect

za, 16/04/2016 - 21:30

I realized a long time ago that I was not the type of person who could create, build & polish ideas all by myself. I need collaboration with others to hone and build ideas. More than not, I’m not the one who starts the idea. I pick up something from someone else – bend it, twist it, and turn it into something different.

Like many others, I have a problem with ‘fear of rejection’, which kept me from shepherding my ideas from beginning to shipped. If I couldn’t finish the idea myself or share it within my trusted circle, the idea would likely die. I had most successes when sharing ideas with others. I have been working to increase the size of the trusted circle, but it still has limits.

Some time last year, Mozilla was doing some annual planning for 2016 and Mark Mayo suggested creating informal pitch documents for new ideas, and we’d put those into the planning process. I created a simple template and started turning ideas into pitches, sending the documents out to a large (it felt large to me) list of recipients. To people who were definitely outside my circle.

The world didn’t end. In fact, it’s been a very positive experience, thanks in large part to the quality of the people I work with. I don’t get worried about feeling the idea isn’t ready for others to see. I get to collaborate at a larger scale.

Writing the ideas into pitches also forces me to get a clear message, define objectives & outcomes. I have 1x1s with a variety of folks during the week, and we end up talking about the idea, allowing me to further build and hone the document before sending it out to a larger group.

I’m hooked! These days, I send out pitches quite often. Maybe too often?

Categorieën: Mozilla-nl planet

Allen Wirfs-Brock: Slide Bite: The Ambient Computing Era

za, 16/04/2016 - 16:41


In the Ambient Computing Era humans live in a rich environment of communicating computer enhanced devices interoperating with a ubiquitous cloud of computer mediated information and services. We don’t even perceive most of the computers we interact with. They are an invisible and indispensable part of our everyday life.

Categorieën: Mozilla-nl planet