Intent to ship: Changing default Japanese fonts to modern fonts

[Masayuki Nakano]

Hi,

We decided that we should change our default Japanese fonts from legacy 
"MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap 
glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho" 
(serif).


This has been enabled on Nightly and early Beta since 55 [1].

Then, I removed the |#ifdef EARLY_BETA_OR_EARLIER| in Nightly yesterday 
[2].  I.e., the new default settings are enabled on release build 
starting from 57.


I'd like to introduce some backgrounds:

"Meiryo" is installed on Vista or later (but not installed on Win10 
unless you add Japanese in system language settings). "Yu Gothic" and 
"Yu Mincho" is installed on Win8.1 or later.


Both Edge and Chrome already started to use "Meiryo" as their default 
Japanese fonts. So, using "Meiryo" improves the compatibility between 
browsers and just looks better and is easier to read than bitmap glyph.


One of the reason why we didn't use "Meiryo" as default fonts is, 
"Meiryo" has normal style glyph as italic style glyph. E.g., 
|abc| looks like |abc|, not |a/b/c|. The other browsers have this 
issue, but I see many users who complain about this issue. For solving 
this issue, we added a hack to ignore italic style family of "Meiryo" at 
loading fonts [3]. So, now, Gecko is the only one engine which supports 
italic style Japanese text with default fonts!


On the other hand, there are still some problems.

"Meiryo" has too big internal leading for supporting accent marks of 
Western languages. This causes increasing normal line height than other 
fonts. Additionally, Gecko's normal line height computation is not same 
as the other browsers. Therefore, this may cause compatibility issue 
with the other browsers. For example, our  allows to scroll its 
content. Therefore, if user drags text in  vertically, the text 
may be scrolled [4].


If we could use "Yu Gothic" as Japanese default font, it'd be really 
nicer except compatibility with the other browsers because it has nicer 
glyph than "Meiryo" ("Meiryo" was designed for UI, not for document. 
Therefore, it was designed as easier to read even if the font size is 
small) and does not have too big leading like "Meiryo".  However, there 
is a big problem. Text renderer of Windows has a bug. Text of "Yu 
Gothic" is rendered as too light [5]. So, the contrast between text and 
background color may not be enough for some users. Therefore, currently, 
we use "Yu Gothic" as a fallback font only when "Meiryo" isn't available.


Anyway, I believe that this makes 57 look nicer for Japanese users!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=548311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1354004
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1351332
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1378065
[5] https://bug548311.bmoattachments.org/attachment.cgi?id=8848439

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox and clang-cl

[Ehsan Akhgari]

On 08/20/2017 09:19 PM, Zachary Turner via dev-platform wrote:

On Monday, August 14, 2017 at 1:47:02 PM UTC-7, Hans Wennborg wrote:

Yes, we want to do LTO+PGO builds eventually. (In particular, we'd
like to use ThinLTO for more manageable build times.) That requires
switching to using the lld linker, which in turn is requires adding
support for writing pdb files, an area that's been making lots of
progress lately.

Cheers,
Hans

A quick update on this, but I wrote a blog post about the state of PDBs in lld 
today.

http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html

TL;DR is that all the hard stuff is done, PDBs are happening, and now it's just 
a matter of finding debug quality issues.  I haven't tried linking Chromium 
with lld yet, but I have tried linking clang with lld and I'm seeing 
/DEBUG:FULL link times with /Z7 being similar to MSVC /DEBUG:FASTLINK times 
with /Zi.

(With all the obvious disclaimers about how as we find / fix debug quality 
issues, things could slow down, since PDB generation without /Zi is a pretty 
big contributor to link time).

If anyone here is up for dogfooding, I would love to have bug reports against 
LLD's PDB debug info quality.
This is great news!  For those who are interested in the very young 
project to port Firefox to link with lld, 
https://bugzilla.mozilla.org/show_bug.cgi?id=linker-lld tracks that work.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Nicholas Nethercote]

On Wed, Aug 23, 2017 at 2:50 AM, Nicholas Alexander 
wrote:
>
>> I really wish our top-level namespace was "moz", rather than "mozilla".
>
> Can you say why?  Is it "just" shorter?  Is it more pleasant to
s/std/moz/ and vice versa?

Mostly because it's shorter. It's good for common names to be short. And
the use of "moz" has plenty of precedent, e.g. the MOZ_ prefix is common in
macros.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Nicholas Alexander]

Hi Nicholas,

On Mon, Aug 21, 2017 at 11:38 PM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:

> I really wish our top-level namespace was "moz", rather than "mozilla".
>

Can you say why?  Is it "just" shorter?  Is it more pleasant to s/std/moz/
and vice versa?

Nick


>
> Nick
>
> On Tue, Aug 22, 2017 at 10:31 AM, Eric Rahm  wrote:
>
> > On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew 
> wrote:
> >
> > >
> > > Wouldn't it be more "modern Gecko-ish", though, to drop the "ns"
> prefix,
> > > and perhaps put Auto[C]String into the mozilla namespace?
> > >
> > >
> > As Nick said, renaming all the things is a job for another day :)
> >
> > Coincidentally I have some pending changes that affect the internal
> naming
> > of all of our strings. Externally (outside of xpcom/string) there will be
> > no discernible change but I *could* move everything to the mozilla
> > namespace and drop the 'ns' prefix. We could then gradually migrate to
> the
> > new naming scheme externally. I think we'd eventually want to move the
> > include path to 'mozilla/String.h' as well if we went this route, in the
> > interim we could just have stubs that redirect to the mozilla path.
> >
> > I'm not sure how much backing that has -- we'd be going from nsString =>
> > String which is pretty close to std::string -- it would be interesting to
> > get some feedback.
> >
> > -e
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #20

[Salvador de la Puente]

Congratulations for this 20th issue of the newsletter and for all the hard
work that the Quantum team is doing!

On Fri, Aug 18, 2017 at 7:36 PM, Olli Pettay  wrote:

>
>
> On 08/18/2017 08:28 PM, Ehsan Akhgari wrote:
>
>> On Fri, Aug 18, 2017 at 9:39 AM, Ryan VanderMeulen <
>> rvandermeu...@mozilla.com > wrote:
>>
>> Is there a good way to get a sense of what the higher-impact bugs are
>> that remain for improving Speedometer? Just going through the deps is
>> difficult because it's hard to assess how much of a win some of those
>> are. Are we gated mostly on JS perf at this point? Layout? Something else?
>> :-)
>>
>>
>> That's a pretty hard question to answer since in many cases the impact of
>> each individual bug fix may fall below the measurement noise in the
>> benchmark score, and also it's pretty hard to map what you see in
>> profiles to benchmark score numbers, except for bugs that have some kind of
>> in
>> progress patch which allows us to measure the before and after state
>> without them having been fixed yet.
>>
>> In general Speedometer performance isn't generally gated on anything
>> extremely big and instead has been improved by fixing many small performance
>> issues all over the place.  That being said, there are some "high
>> profile" bugs that come to my mind.  Jan may think of some more in
>> SpiderMonkey:
>>
>>   * https://bugzilla.mozilla.org/show_bug.cgi?id=651120 I think will be
>> able to gain us a few extra points but it's a complex change with many
>> dependencies and a few people are helping out Cătălin with it.
>> (Interestingly I just realized it wasn't on the dependency list of the main
>> SM2 bug!)
>>
> /me would like to see some Speedometer numbers from a build with the
> patches for bug 651120
>
>   * https://bugzilla.mozilla.org/show_bug.cgi?id=1346723 may also help
>> some more still.  We have already done a ton of work under that bug, but
>> there's some more work to be done.  However this bug is getting closer to
>> the state where most of the remaining work involves fixing many different
>> issues, each of which is costing a bit of the overall time spent there
>> when running the benchmark.
>>   * https://bugzilla.mozilla.org/show_bug.cgi?id=1349255 is a sync IPC
>> that hurts Speedometer so fixing it may have an outsized impact relative to
>> other bug fixes.
>>
> I thought this would affect Speedometer significantly, since it shows up
> in the profiles, but I disabled the sync message altogether and rerun and
> couldn't really see difference locally. Perhaps the sync calls happen
> usually when Speedometer isn't running tests but just loading pages or so.
>
>   * https://bugzilla.mozilla.org/show_bug.cgi?id=1377131 may have a large
>> impact also, but I'm not sure exactly how much.  Olli may be able to provide
>> more information about that.
>>
> Locally my patches seem to affect quite a lot on linux, but unfortunately
> less on Windows.
>
>
>> Cheers,
>> Ehsan
>>
>>
>> Thanks!
>>
>> -Ryan
>>
>>
>> On Fri, Aug 18, 2017 at 1:26 AM, Ehsan Akhgari <
>> ehsan.akhg...@gmail.com > wrote:
>>
>> Hi everyone,
>>
>> It is hard to believe that we've gotten to the twentieth of these
>> newsletters.  That also means that we're very quickly approaching the finish
>> line for this sprint.  We only have a bit more than five more
>> weeks to go before Firefox 57 merges to beta.  It may be a good time to
>> start to
>> think more carefully about what we pay attention to in the
>> remaining time, both in terms of the risk of patches landing, and the
>> opportunity
>> cost of what we decide to put off until 58 and the releases after.
>>
>> We still have a large number of triaged bugs
>> > 22[qf%3Ap%22%20%40nobody%40mozilla.org> that are available for someone
>> to pick up
>> and work on.  If you have some spare cycles, we really would
>> appreciate if you consider picking one or two bugs from this list and
>> working on
>> them.  They span many different areas of the codebase so finding
>> something in your area of interest and expertise should hopefully be simple.
>> Quantum Flow isn't the kind of project that requires fixing every
>> single one of these bugs to be finished successfully, but at the same time
>> big performance improvements often consist of many small parts,
>> so the cumulative impact of a few additional fixes can make a big impact.
>>
>> It is worth mentioning that lately while lurking on various tech
>> news and blog sites where Nightly users comment, I have seen quite a few
>> positive comments about Nightly performance from users.  It's
>> easy to get lost in the details of the work involved in getting rid of
>> synchronous IPCs, synchronous layout/style flushes, unnecessary
>> memory 

Moving from xulrunner to firefox SDK

[Manish]

Hi, 

I am working on a desktop application named "AZARDI" which is based on 
xulrunner. It is an offline ePub Reader for all three major platforms (Windows, 
Mac, Linux). You can check it out at http://azardi.infogridpacific.com/. 

I have been deploying the application successfully with xulrunner 41 and 
earlier. Its been long since Xulrunner has been deprecated so now I am planning 
to deploy it with firefox-sdk. But the problem is from where can I find the 
latest firefox SDK version for all the platforms eg: windows, linux and mac. 
Second can the directory structure remains the same as earlier like for 
xulrunner.

Any help will be useful. 

Thanks in advance.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Mike Hommey]

On Tue, Aug 22, 2017 at 04:38:04PM +1000, Nicholas Nethercote wrote:
> I really wish our top-level namespace was "moz", rather than "mozilla".

It's never too late to change it. I, for one, vote +1.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Nicholas Nethercote]

I really wish our top-level namespace was "moz", rather than "mozilla".

Nick

On Tue, Aug 22, 2017 at 10:31 AM, Eric Rahm  wrote:

> On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew  wrote:
>
> >
> > Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix,
> > and perhaps put Auto[C]String into the mozilla namespace?
> >
> >
> As Nick said, renaming all the things is a job for another day :)
>
> Coincidentally I have some pending changes that affect the internal naming
> of all of our strings. Externally (outside of xpcom/string) there will be
> no discernible change but I *could* move everything to the mozilla
> namespace and drop the 'ns' prefix. We could then gradually migrate to the
> new naming scheme externally. I think we'd eventually want to move the
> include path to 'mozilla/String.h' as well if we went this route, in the
> interim we could just have stubs that redirect to the mozilla path.
>
> I'm not sure how much backing that has -- we'd be going from nsString =>
> String which is pretty close to std::string -- it would be interesting to
> get some feedback.
>
> -e
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform