[Sugar-devel] Font Editor Activity || GSoC 2016

[Dave Crossland]

Hi!

On 21 April 2016 at 19:40, Mredul Sarda <mredul.sarda at gmail.com> wrote:

>  am a student from a university in India applied for GSoC 2016. I have
> applied for Font Editor Activity under mentor Dave.
>
Thanks again for your proposal - I'm sorry it was not selected.

> I have started working around with the sugar activities. Just to mention
> that I found working with sugarizer more easier, I would prefer working on
> this web based activity if given a choice. However, Sugar Activities are
> more widespread among the education community so it might be a better
> option to start with. It would be great to have some opinions from the core
> Sugar Community about how do they look into the future of this activity. It
> is important that we are clear about our choices before starting.
>
For me personally, I am not too biased towards python or javascript... I
must admit that prefer writing python programs and using javascript ones ;)


Well, for this project, it is simple: The coding mentor for the project,
Eli, is more interested in Python, so I suggest that the Font Editor
activity be written in Python.

But generally, I think that to decide if a new Activity should be in python
or js, it is wise to the end users must be kept in mind. It seem that the
majority of Sugar users are using the XO laptop, and today there are very
few users of Sugarizer (although no one really knows how many there are,
but it surely can not be over 10,000, whereas it seems to me personally
likely that there are still 10,000 active Sugar users.)

Mobile is going up up up right now, and at the moment, the Sugar community
has developed Sugarizer as a way to bring Sugar Activity designs to any
child who wants to learn with them... But it still in a relatively early
stage. So it is probably best to write a standalone web application for
kids, that can be packaged for Android, iOS and Sugar; Jamie's decision to
do this seems instructive.

Even for the world's children, per
http://ben-evans.com/benedictevans/2014/10/28/presentation-mobile-is-eating-the-world,
"mobile is eating the world" and desktops and laptops are in terminal
decline:

[image: Inline images 2]


You don't hear this term much any more, but when I was a boy (I'm 33 now)
then the term for a "desktop" before the 90s "wintel" era was a
"micro-computer." (In fact this is where the company name "Microsoft"
originates from; initially that company was called "Micro-soft" ;)

This name made sense in the 70s and 80s because back then, the
https://en.wikipedia.org/wiki/Minicomputer was as dominant and professional
and serious and productive as desktop/laptops are today; like the PCs in
the above graph, they ran a curve up from the mid 60s to the mid 70s, and
when were at their peak, the earliest micro-computers were kind of silly -
https://en.wikipedia.org/wiki/Apple_I is from 76, just look at it :)

But then mini-computers were in terminal decline, down to the late 90s when
less savvy people spent a lot of money bailing out their failing dot com
start up's crappy software by using their VC money to buy bigger
mini-computers ;) Meanwhile more savvy people built server farms out of GNU
servers on cheap commodity PC hardware; the reason Google's brand colors
are what they are is because the first server racks for those cheap PC
motherboards were made out of the similarly colourful lego bricks ;) And
now today, minicomputers are totally gone, I think - although mainframes
persist. Maybe someone here knows of minicomputers in use today? :D

Anyway. The point is that all desktops and laptops - from Windows on down -
are going away, and likely much faster than minicomputers went away. So I
don't think it makes much sense to invest too much in desktop systems, no
matter what language they are written in.

About 3 years ago I helped initiate an 'advanced' font editor project, that
started in Python, and then after a year of prototyping, was restarted in
JavaScript and worked on by a small team (http://www.metapolator.com). It
still isn't really useful, and partly that's because so little existing
font editor libraries existed in JavaScript, so the team had to write a lot
of 'foundational' parts themselves. We understood at the time we'd be
moving our starting position back, and today a lot of the foundational
parts needed for a web based font editor now exist :) At the time I
explained why we chose JavaScript/web-platform in
https://github.com/metapolator/metapolator/wiki/faq#why-is-metapolator-a-web-tool


But in learning about the history of OLPC and Sugar, I have been quite
astonished to learn about Squeak and EToys. I think it would be exciting to
write a font editor in Squeak, and it seems Squeak is very capable of
running on any platform - even inside web browsers.

So, Mredul, since in a prior private email you said you won't be able to
contribute to the effort with out the GSOC funding, I do recommend spending
some time learning about Squeak. I think you'll get a lot of value out of
it :)

> I was going through TruFont app to identify the basic features and icons
> for the Sugar Activity. I understand that the pencil in their case itself
> has the Bezier Curves Algorithm implemented. However I feel that it should
> be separately implemented with another icon to twist the line drawn using
> the algorithm.
>
Yes, I agree, there should be a tool for adding points, a tool for moving
points, and a tool for removing points.

> Secondly, I think we should put up lines or grids, so as to accurately
> place the characters and glyphs and better finishing.
>
I agree, although the guidelines should not be square, like graph paper,
but rather based on horizontal alignments and on vertical 'cadence.'

> These are some small level improvisations possible. I am thinking more on
> the lines of Paint Activity with more control over the position and
> dimensions of glyphs.
>
(Paint is a raster graphics application, whereas fonts are vectors.)

> I have locally tried to edit the Paint Sugar Activity according to our
> requirements because many of the basic features remain exactly same. I
> would like to have inputs from the Sugar Community on the concerns and
> suggestions mentioned above.
>
> Looking forward for your reply.
>
Me too :)

-- 
Cheers
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160424/69545c05/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smartphone-growth41.jpg
Type: image/jpeg
Size: 134803 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160424/69545c05/attachment-0001.jpg>