Intent to prototype: Default font metrics overriding

Summary: For historical/legacy reasons, fonts may contain multiple, conflicting versions of key metrics such as line ascent and descent, and user agents/platforms may rely on different fields in the font. This results in inconsistencies in line spacing, baseline alignment, etc. To enable

Intent to prototype: glyph-scale-factor descriptor for @font-face rules

Summary: For a given "font size" as expressed e.g. in CSS px or points, different fonts can vary significantly in how visually large they look. The nominal "font size" does not necessarily relate to any specific dimension of the glyphs; it sizes the coordinate space within which the glyph

PSA: potential new source of intermittent test failures - and how to work around it

Do you write Gecko/Firefox patches or testcases, or monitor the Mozilla trees? If so, you may run into new intermittent test failures due to a recent (intentional) behavior change. On 2020-12-31, a patch landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1676966 that changed how font

Re: A new testing policy for code landing in mozilla-central

On 15/09/2020 16:03, Brian Grinstead wrote: > We’re rolling out a change to the review process to put more focus on automated testing. [...] As others have said, it's great that we're setting a clearer policy here - thanks! One thing did strike me as a little surprising, and could perhaps

Intent to implement and ship: updated values for text-decoration properties

There have been some recent changes to the CSS spec for the text-decoration-thickness, text-underline-offset, and text-underline-position: support for percentage values (based on the font-size) is added to the -thickness and -offset properties, as an alternative to using absolute lengths; and

Intent to implement and partially ship: extended TextMetrics attributes for canvas text measurement

The TextMetrics interface represents the dimensions of a piece of text in the canvas, as created by the CanvasRenderingContext2D.measureText() method. Currently, Gecko only supports the .width attribute, but authors would also like to determine the actual dimensions that the rendered text

Intent to ship: text-underline-position

I'm shortly intending to turn on support for the CSS property text-underline-position on all platforms. This feature was developed behind the preference "layout.css.text-underline-position.enabled". Other UAs shipping this feature: * Internet Explorer v6 (an earlier non-standard version of the

Re: Intent to prototype: CSS property `text-underline-position`

On 06/12/2019 09:35, James Graham wrote: On 03/12/2019 17:50, Jonathan Kew wrote: web-platform-tests: https://wpt.fyi/results/css/css-text-decor/parsing?label=master=text-underline-position That looks like it's just testing the property computation. Do we also have tests for the layout

Intent to prototype: CSS property `text-underline-position`

[re-sending, with a web-platform-tests link included - sorry!] Summary: This property offers authors added control of the positioning of underlines, primarily for vertical text (where conventions differ as to whether an "underline" should appear to the left or right of the text), and also for

Intent to prototype: CSS property `text-underline-position`

Summary: This property offers authors added control of the positioning of underlines, primarily for vertical text (where conventions differ as to whether an "underline" should appear to the left or right of the text), and also for horizontal text where a lower underline may be desirable (e.g.

Re: Intent to ship: Web Speech API

On 07/10/2019 09:53, Henri Sivonen wrote: On Mon, Oct 7, 2019 at 5:00 AM Marcos Caceres wrote: - speech is processed in our cloud servers, not on device. What should one read to understand the issues that lead to this change? +1. This seems like a change of direction which has *huge*

Re: What to do about scroll anchoring?

On 27/09/2019 23:19, Botond Ballo wrote: Emilio, thanks for all your work on this! On Fri, Sep 27, 2019 at 8:23 AM Emilio Cobos Álvarez wrote: Does anyone have strong opinions against removing scroll anchoring from Gecko, based on the above? My 2c: it would be unfortunate to give up on

Re: Watch out for build issues on non-Unicode systems

On 22/08/2019 13:42, Nihanth Subramanya wrote: Note that the config.status changes in bug 844509 seem to break `$./mach clobber` - I had to manually rm -rf my objdir. Ah, that'll be what just happened to me, too. (Not just ./mach clobber, I was getting the same failure with ./mach build as

Intent to prototype and ship: CSS `quotes: auto`

Summary: Adding a new `auto` value as the initial value of CSS `quotes` property, with the behavior that language-sensitive quotation marks (derived from CLDR) are used for quote-open/close generated content. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1421938 Standard:

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

Great to see this consolidation happening; it's going to be a great improvement on the current situation. Just to check, would it be correct to assume this won't be landing on central until after the current Fx68 soft-freeze period? It seems like the sort of wide-ranging change that probably

Intent to implement: CSS line-break property

Summary: The `line-break` property allows authors more control over where soft line breaks are allowed, particularly for East Asian content. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1011369 https://bugzilla.mozilla.org/show_bug.cgi?id=1531715 Link to standard:

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On 01/05/2019 17:29, Randell Jesup wrote: Jean-Yves writes: If anyone is chomping at the bit to remove 1proc support from their module, please speak up. I am one of those developers that find non-e10s essential to debug core features. I've depended on using non-e10s for ages as well. Most

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

On 09/04/2019 20:44, Andrew Halberstadt wrote: Yeah, I did consider "non-e10s" for awhile and maybe it is the better choice. But here are my counter arguments: 1) One of the goals of this change is to de-clutter the treeherder UI. Using an 8 character symbol suffix runs counter to that goal

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

On 03/01/2019 16:17, jmaher wrote: I would like to propose that we do not run tests on linux64-opt, windows7-opt, and windows10-opt. Why am I proposing this: 1) All test regressions that were found on trunk are mostly on debug, and in fewer cases on PGO. There are no unique regressions found

Re: The upcoming C/C++ coding style change

On 13/12/2018 14:52, Randell Jesup wrote: But still all is not lost here. When you do decide to do the manual merging when you needed those patches, you would need to: * Update your working tree to the parent of the commit that did the reformat. * Apply your patch to that tree and reformat

Re: Dropping support for compiling with MSVC in the near future

On 06/12/2018 15:00, Ted Mielczarek wrote: Hello, In light of the fact that we've switched to clang-cl for our Windows builds[1], we are planning to drop support for compiling Firefox with MSVC in the near future[2]. Our estimate is that this will happen sometime in Q1. Supporting more than

Re: Proposed W3C Charter: Web Fonts Working Group

On 16/11/2018 12:39, Xidorn Quan wrote: On Fri, Nov 16, 2018, at 11:12 AM, L. David Baron wrote: The W3C is proposing a revised charter for: Web Fonts Working Group https://www.w3.org/Fonts/WG/webfonts-2018-ac.html https://lists.w3.org/Archives/Public/public-new-work/2018Oct/0015.html

Re: Intent to ship: scrollbar-color and scrollbar-width properties

On 26/09/2018 01:59, Xidorn Quan wrote: As of Firefox 64, I intend to turn scrollbar-color and scrollbar-width properties on by default on all platforms. They have been developed behind pref "layout.css.scrollbar-colors.enabled" and "layout.css.scrollbar-width.enabled" respectively. Awesome,

Re: PSA: Major preference service architecture changes inbound

On 20/07/2018 03:25, Kris Maglione wrote: On Thu, Jul 19, 2018 at 07:17:13PM -0700, Jeff Gilbert wrote: Using a classic read/write exclusive lock, we would only every contend on read+write or write+write, which are /rare/. That might be true if we gave up on the idea of switching to Robin

Re: PSA: Major preference service architecture changes inbound

it probably is, too. If we're only using it off-thread in a few places, and don't have to worry about contention, why are we bothering with locking and off-thread access in the first place? On Tue, Jul 17, 2018 at 8:57 AM, Kris Maglione wrote: On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan

Re: PSA: Major preference service architecture changes inbound

On 13/07/2018 21:37, Kris Maglione wrote: tl;dr: A major change to the architecture preference service has just landed, so please be on the lookout for regressions. We've been working for the last few weeks on rearchitecting the preference service to work better in our current and future

Re: Intent to ship: OpenType Variation Font support

On 13/05/2018 14:01, rosesharon...@gmail.com wrote: On Monday, March 19, 2018 at 3:32:42 PM UTC-7, Jonathan Kew wrote: As of this week, for the mozilla-61 cycle, I plan to turn support for OpenType Font Variations on by default. It has been developed behind the layout.css.font

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

On 03/05/2018 00:57, Emma Humphries wrote: To summarize, when you are releasing a feature that "rides behind a flag", on the bug for the feature: * set the behind-pref flag to + * set the qa-verify flag to ? * note the bug in the Firefox Feature Trello board We expect qa-verify to be set to

redundant(?) code churn and code style issues in bug 525063

The huge patch that recently hit mozilla-central in bug 525063 makes me a bit sad. Did we really need to do this? On this scale? It's presumably auto-generated by a static-analysis tool or something like that, but ISTM it has been overly aggressive, adding a lot more code churn than necessary

Re: Intent to ship: OpenType Variation Font support

On 21/03/2018 08:03, dr...@chromium.org wrote: font-{weight,stretch,style} are parsed and hooked up to the variable fonts rasterization backend since we initially shipped OpenType Variations in M62. I implemented this in Blink, so if you are observing any issues, mind sharing them? I'd be

Re: Intent to ship: OpenType Variation Font support

On 20/03/2018 20:50, gwhi...@gmail.com wrote: Will 61 bring support for font-optical-sizing as well? Yes; it's behind the same pref as font-variation-settings, so the two properties will be enabled together. ___ dev-platform mailing list

Re: Intent to ship: OpenType Variation Font support

On 19/03/2018 22:42, L. David Baron wrote: Is there something with a little more detail about how our (a) feature set and (b) platform support compares with what other engines are shipping? That sounds like it could be a worthwhile blog post somewhere In brief: everyone supports

Re: Intent to ship: OpenType Variation Font support

On 20/03/2018 09:54, James Graham wrote: On 19/03/2018 22:32, Jonathan Kew wrote: As of this week, for the mozilla-61 cycle, I plan to turn support for OpenType Font Variations on by default. It has been developed behind the layout.css.font-variations.enabled

Intent to ship: OpenType Variation Font support

As of this week, for the mozilla-61 cycle, I plan to turn support for OpenType Font Variations on by default. It has been developed behind the layout.css.font-variations.enabled and gfx.downloadable_fonts.keep_variation_tables preferences. Other UAs shipping this or intending to ship it

Intent to ship: CSS paint-order for HTML text

As of Firefox 60, I intend to turn CSS paint-order for HTML text on by default. It has been developed behind the layout.css.paint-order.enabled preference. I am not aware of any other UAs yet shipping this feature, but since our intent to implement, the CSS WG has agreed to include this in

Intent to implement: support CSS paint-order for HTML text

Summary: For text that is stroked as well as filled (using -webkit-text-stroke), this allows the author to control whether the stroke is painted before or after the fill. The current behavior is to always paint the stroke on top, which is often visually poor, and leads authors to use

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On 05/12/2017 15:16, Henri Sivonen wrote: On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki wrote: There are other non-ASCII character issues such as https://bugzilla.mozilla.org/show_bug.cgi?id=1258613 Very weird bug! (Summary for others: decomposed voiced sound mark is

Re: Hiding 'new' statements - Good or Evil?

On 23/11/2017 12:05, Jeff Gilbert wrote: I agree that MakeNotNull doesn't sound like it allocates. Reads to me as Make[Into]NotNull. Context will *usually* make this clear, but why not NewNotNull? (Honestly I don't like MakeUnique to begin with) As far as naming is concerned, ISTM that

Re: Visual Studio 2017 coming soon

On 26/10/2017 15:14, Milan Sreckovic wrote: Are we locked into using the same compiler for the ESR updates?  In other words, do we need to keep VS2015 for ESR52 builds until they are not needed anymore? Yes, IMO. Whether or not we're "locked" in any technical sense, I think we should

Re: Changes to tab min-width

On 06/10/2017 17:05, Boris Zbarsky wrote: On 10/3/17 5:18 PM, Boris Zbarsky wrote: So just to make sure I understand the change (and this is a theoretical point, because I haven't had a chance to try the change yet)... OK, now I have had a chance to try it. When set to the new 50px

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

On 04/10/2017 09:17, Jan Keromnes wrote: You can also run them on your own code with: ./mach static-analysis check path/to/file.cpp Sounds awesome! I tried this locally to see what it would say about a random(ish) file in the tree, but it ended with the message: 0:42.99 Could not find

Re: Status of CSS break-* properties

On 13/09/2017 12:31, thomas.ja...@gmail.com wrote: Hi there! Apparently, most major browsers are currently supporting "break-column", e.g., or its "-webkit-column-"-prefixed variant (based on manual testing of https://www.quirksmode.org/css/columns/breaks.html in latest Chrome, Safari, Edge

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

On 20/08/2017 23:35, Nicholas Nethercote wrote: Hi, For a long time we have had types nsAutoString and nsAutoCString which are strings with 64 chars of inline storage. They are good for holding short strings, most often on the stack, because they avoid the need to heap allocate a char buffer.

Re: Changing .idl files

On 07/08/2017 18:05, Kris Maglione wrote: At the moment, legacy add-ons are allowed on nightly, but are officially unsupported. We're planning to disable them by default on nightlies, but it will still be possible to enable them by flipping a pref. Will that pref still be available in 57 once

Intent to ship: CSS font-display descriptor

For Firefox 57, I intend to turn the CSS 'font-display' descriptor for @font-face rules on by default. This feature was developed behind the layout.css.font-display.enabled preference. Blink has already shipped this feature as of Chrome 60:

Re: Mozilla Charset Detectors

On 22/05/2017 10:13, Gabriel Sandor wrote: Greetings, I recently came across the Mozilla Charset Detectors tool, at https://www-archive.mozilla.org/projects/intl/chardet.html. I'm working on a C# project where I could use a port of this library (e.g. https://github.com/errepi/ude) for advanced

Re: Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

On 18/01/2017 07:04, Henri Sivonen wrote: I'm in the process of rewriting our encoding converter infrastructure in Rust. For a new implementation, it makes sense to support only the Web-exposed encodings, that is, the encodings specified in the Encoding Standard. Currently, Firefox supports

Re: Intent to ship: NetworkInformation

On 15/12/2016 17:20, Ben Kelly wrote: On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky wrote: On 12/15/16 11:23 AM, Ben Kelly wrote: if (navigator.connect.downlinkMax > 100) { // perform low-priority background downloads } Why is the downlinkMax the right thing to be

Re: Intent to implement: OpenType Variation Fonts

On 06/12/2016 19:04, Xidorn Quan wrote: On Tue, Dec 6, 2016, at 01:28 AM, Jonathan Kew wrote: DevTools bug: It's not yet clear to me whether specific DevTools work will be needed, beyond the support we'll automatically get for a new CSS property. I think DevTools may want to display a panel

Intent to implement: OpenType Variation Fonts

We're proposing to implement support for OpenType Variation Fonts in Gecko. From the Microsoft announcement[1] of Font Variations technology: "...make use of a variety of font weights and styles to make your message stand out clearly. The problem has been that all those weights and

Intent to deprecate and then unship: nsIScriptableDateFormat

We're proposing to remove the XPCOM service nsIScriptableDateFormat, used for locale-appropriate formatting of date/time values.[1] Front-end code that needs this functionality should move to the standard JS i18n APIs.[2,3] I've got a bunch of patches just about ready to land in [4] that

Re: Removing the Battery Status API?

On 26/10/2016 08:30, Chris Peterson wrote: What is the use case for the Battery Status API [0], navigator.getBattery()? Can we remove the Battery API or perhaps restrict it to non-web content like browser extensions or privileged web apps? Chrome and Firefox support the Battery API, but neither

Re: Why I don't like DXR

On 26/9/16 14:14, Honza Bambas wrote: Today I tried to search for an identifier on DXR. Something that was so easy with MXR... I wanted to find usage of a member called "io_pending". Typing that string to the DXR search field gives me a number of results that are definitely not what I'm

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On 1/6/16 00:51, Nicholas Nethercote wrote: On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew <jfkth...@gmail.com> wrote: I took a quick look at a random one of these OOMs[1], and what strikes me about it is that according to the crash report: Total Virtual Memory2147

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On May 31, 2016, at 2:22 , Nicholas Nethercote wrote: #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument given. These are mostly OOMs, though there are a few others in there. These ones should be annotated so they show up separately. I took a quick

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

start assuming support for compiler and/or runtime library features that aren't readily available there. JK -Jeff On Thu, Apr 28, 2016 at 1:00 PM, Jonathan Kew <jfkth...@gmail.com <mailto:jfkth...@gmail.com>> wrote: We make considerable (and growing) use of ICU for var

ICU proposing to drop support for WinXP (and OS X 10.6)

CC: ICU support mailing list <icu-supp...@lists.sourceforge.net>, Jonathan Kew <jonat...@jfkew.plus.com> On Wed, Apr 27, 2016 at 4:30 PM, Steven Loomis <s...@icu-project.org <mailto:s...@icu-project.org>> wrote: Jonathan and other users, Please comment on

Re: Moving XP to ESR?

On 20/4/16 20:14, Ben Hearsum wrote: This would require a new update channel to support, because it would be a unique line of code that isn't "release" or "esr". It couldn't be implemented as a relbranch either, because we'd need CI for it. You're basically proposing a long lived esr-like

Re: Dan Stillman's concerns about Extension Signing

On 30/11/15 15:45, Gavin Sharp wrote: and it's definitely the wrong thing to do. Fundamentally the add-on signing system was designed with an important trade-off in mind: security (ensuring no malicious add-ons are installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring that

Re: Intent to ship: vertical text support (CSS writing-mode and related properties)

On 1/7/15 11:21, Robert O'Callahan wrote: So tables and flexbox will be fixed in 41 too? Both of them are largely working in 41 at this point; I believe they're usable for most common use-cases. For tables, the main limitation is that caption is not yet placed correctly; that should follow

Re: Intent to ship: vertical text support (CSS writing-mode and related properties)

On 1/7/15 13:06, Sebastian Zartner wrote: CSS Logical Properties Level 1 doesn't even in WD status yet. Therefore I assume everything in there can still change fundamentally. So are you sure logical properties should be shipped already? Could the writing mode features perhaps be shipped

Intent to ship: vertical text support (CSS writing-mode and related properties)

specifications: http://dev.w3.org/csswg/css-writing-modes-3/ http://dev.w3.org/csswg/css-logical-props/ JK On 2/3/15 12:59, Jonathan Kew wrote: See [1] for additional background on this feature. We are aiming to enable support for CSS writing-mode and related features (i.e. vertical text support

Intent to ship *on pre-release channels* : vertical text support (CSS writing-mode and related properties)

See [1] for additional background on this feature. We are aiming to enable support for CSS writing-mode and related features (i.e. vertical text support) in Gecko 39.[2] This will be enabled behind an #ifndef RELEASE_BUILD condition, so that for the time being, these features will be

Re: Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images

On 7/2/15 10:24, Kyle Huey wrote: Why don't we just click to play everything? Yes, we should do that. At least as an option, exposed in Preferences: something like [ ] Never auto-play video or audio or [ ] Always show a Click to Play control for media I'd suggest it belongs in

Intent to implement and ship: vertical text support (CSS writing-mode and related properties)

We are working on support for v e r t i c a l text in Gecko. This will allow web content (and eventually complete web apps, if desired) to use vertical writing, as traditionally used in East Asia. In addition to the CSS writing-mode property, this will involve support for

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On 15/1/15 15:56, ISHIKAWA,chiaki wrote: Debugging using gdb will be very difficult when the unified build creates a source file on the fly (but it is removed, correct?). No sane compiler/debugger combination can help me do the source level debugging if the source code that the compiler

Re: Unified compilation is going to ride the train

On 28/11/14 08:46, L. David Baron wrote: On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote: The downside from doing so, though, is that non-unified build *will* be broken, and code purity (right includes in the right sources, mostly) won't be ensured. Do you think this is important enough to

Re: Unified compilation is going to ride the train

On 28/11/14 14:36, Ehsan Akhgari wrote: The question is: what do we gain from doing that, technical purity aside? Note that as Mike mentioned, even with doing both unified and non-unified builds, you may still get build failures when adding/removing .cpp files, so keeping support for

Re: Intent to implement: WOFF2 webfont format

On 8/10/14 15:44, Patrick McManus wrote: On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham g...@mozilla.org mailto:g...@mozilla.org wrote: On 07/10/14 14:53, Patrick McManus wrote: content format negotiation is what accept is meant to do. Protocol level negotiation also allows

Re: Intent to implement: WOFF2 webfont format

On 8/10/14 16:48, Patrick McManus wrote: On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus mcma...@ducksong.com mailto:mcma...@ducksong.com wrote: intermediaries, as I mentioned

Re: Intent to implement: WOFF2 webfont format

On 3/10/14 01:11, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew jfkth...@gmail.com wrote: Or do people need to hardcode UA versions to know what UAs support it? I believe that's what Google Fonts currently does, though IMO a better approach is to serve CSS that offers

Intent to implement: WOFF2 webfont format

The W3C WebFonts Working Group[1] has been working on designing and specifying a new compressed font format for the web, aiming to give significantly smaller file sizes than the existing WOFF format (to reduce bandwidth requirements), while remaining cheap to decode (for low-power devices).

Re: Intent to implement: WOFF2 webfont format

On 2/10/14 16:20, Ralph Giles wrote: On 2014-10-02 4:03 AM, Jonathan Kew wrote: The format is primarily based on earlier TrueType compression work (MicroType Express) by Monotype, and a new entropy coder (Brotli) developed by Google's data compression team in Zurich. What kind of filesize

Re: Icon fonts in FxOS

*From: *Anne van Kesteren ann...@annevk.nl *To: *Wilson Page wilsonp...@mozilla.com *Cc: *Jonathan Kew j...@mozilla.com, Patryk Adamczyk padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org, L. David Baron dba...@mozilla.com, Jaime Chen jac

Re: Icon fonts in FxOS

on its needs. (Presumably it'd be simple to scan the app's files and determine exactly which icons it needs.) JK W. *From: *Jonathan Kew j...@mozilla.com *To: *Wilson Page wilsonp...@mozilla.com, Jet Villegas j

Re: Icon fonts in FxOS

On 16/6/14 22:09, James Burke wrote: On 6/16/14, 12:34 PM, Jet Villegas wrote: I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they

Re: Intent to ship: Hyperlink Auditing (a ping)

On 16/5/14 10:29, Tim Taubert wrote: *Link to Standard* http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing A couple of quotes from there: User agents should allow the user to adjust this behavior, for example in conjunction with a setting that disables the sending of HTTP

Re: Intent to ship: Hyperlink Auditing (a ping)

On 16/5/14 13:02, L. David Baron wrote: On Friday 2014-05-16 12:49 +0100, Jonathan Kew wrote: When I click a Google search result (for example), I can see -- thanks to the status overlay that shows the URLs being requested -- that it's redirecting me via a Google URL that is presumably being

Re: Intent to ship: Hyperlink Auditing (a ping)

On 16/5/14 14:37, Kyle Huey wrote: On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig curt...@mozilla.com wrote: On 16 May, 2014, at 09:11 AM, Tim Taubert ttaub...@mozilla.com wrote: I think it really might make sense to remove the preferences altogether Given our stance on privacy[1] and

Re: Controlling font size as per system DPI in Windows

On 1/4/14 13:05, bhargava.animes...@gmail.com wrote: Hi, We have a property in greprefs.js layout.css.dpi by which we can control pixel size , but this doesn't work in Windows. There is another property layout.css.devPixelsPerPx which control font size in Windows but this needs to be modified

Re: Including Adobe CMaps

On 28/2/14 11:44, Gervase Markham wrote: On 26/02/14 20:21, Jonathan Kew wrote: Lets turn this question around. If we had an on-demand way to load stuff like this, what else would we want to load on demand? A few examples: Spell-checking dictionaries Hyphenation tables Fonts for additional

Re: Including Adobe CMaps

On 26/2/14 19:57, Andreas Gal wrote: Lets turn this question around. If we had an on-demand way to load stuff like this, what else would we want to load on demand? A few examples: Spell-checking dictionaries Hyphenation tables Fonts for additional scripts JK Andreas On Feb 26, 2014,

Re: Platform-specific nsICollation implementations

On 25/11/13 11:16, Henri Sivonen wrote: Now that we have ICU in the tree, do we still need platform-specific nsICollation implementations? In particular, the Windows and Unix back ends look legacy enough that it seems that making nsICollation ICU-backed would be a win. In particular, this

Re: What platform features can we kill?

On 9/10/13 17:18, Boris Zbarsky wrote: On 10/9/13 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? * XSLT (Chrome have already announced they will remove it: Have they? I admit I haven't made it through every post in their discussion

Re: Introducing Brotli - an alternative to LZMA

On 11/9/13 14:12, Jeff Muizelaar wrote: Brotli increases the window size and thus memory requirement to 4MB which is quite a bit. It's also larger than the cache size on mobile devices which is currently around 1MB so it would be interesting to see decompression speeds on small cache devices.

Introducing Brotli - an alternative to LZMA

[tl;dr] Considering the use of LZMA [or bzip2?] somewhere in the web platform, for improved compression compared to gzip algorithms? Take a look at a new project, Brotli, an alternative with several potential benefits: - formal specification will be available - commitment to security

Re: Including algorithm just to get std::min and std::max

On 9/9/13 00:29, Nicholas Cameron wrote: I don't think these kind of time improvements make it worth duplicating std library code into mfbt, we may as well just pull in the headers and forget about it. +1 to that. We've been trying to get *away* from requiring special Mozilla-isms in our

Re: Feedback wanted on font checker

On 9/8/13 15:36, Axel Hecht wrote: So I created three test cases based on the data I see, Greek and Bulgarian monospace and Hindi sans-serif. They're linked off of http://pike.github.io/fonts/. It's prerendered images on the left column, and regular text on the right. Hindi is blank squares

Re: Feedback wanted on font checker

On 8/8/13 15:17, Axel Hecht wrote: Hi, I'm looking for a review of some rather hacky tool I just created to see if the fonts on b2g actually support a particular language. https://github.com/Pike/font-tool Basic outline of what the tool does: Parses langGroups.properties to see which locale

Re: Some data on mozilla-inbound

On 23/4/13 09:58, Neil wrote: Kartikaya Gupta wrote: The vast majority of changesets that are backed out from inbound are detectable on a try push Hopefully a push never burns all platforms because the developer tried it locally first, but stranger things have happened! But what I'm most

Re: End of life for tinderbox.mozilla.org

On 3/4/13 15:32, Ed Morley wrote: On 03 April 2013 15:21:33, Neil wrote: Since tinderboxpushlog no longer uses tinderbox, maybe it should get renamed ;-) Agreed - TBPL's successor is going to be called something other than TBPL2 (name chosen so far is treeherder). I presume it'll be at

Re: Synchronous loading of data: URLs

On 11/12/12 10:51, Neil wrote: Neil wrote: Jonathan Kew wrote: You shouldn't normally see a flash of fallback text unless the font is particularly slow to load; the text should be invisible until the font is available. We aim to hide the text until the font is ready, unless it takes more

Re: Synchronous loading of data: URLs

On 11/12/12 12:18, Henri Sivonen wrote: On Wed, Dec 5, 2012 at 5:37 AM, John Daggett moz.li...@windingwisteria.com wrote: Fonts are loaded when used so font loading won't start until the contents using a particular font are laid out. That seems like a problem for JS-driven display. A big

Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)

On 17/10/12 14:17, Zack Weinberg wrote: On 2012-10-17 4:07 AM, Henri Sivonen wrote: On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg za...@panix.com wrote: Until quite recently the FreeType autohinter did a very bad job on a surprising number of popular webfonts - rendering letters in the same

Re: Proposed W3C Charter: Web Fonts Working Group

On 16/10/12 14:42, Henri Sivonen wrote: On Thu, Oct 11, 2012 at 7:54 PM, L. David Baron dba...@dbaron.org wrote: W3C is proposing a revised charter for the Web Fonts Working Group. For more details, see: http://lists.w3.org/Archives/Public/public-new-work/2012Sep/0016.html

Re: W3C Proposed Recommendation: WOFF File Format 1.0

On 15/10/12 15:28, alexander.alis...@gmail.com wrote: Any properly licensed TrueType/OpenType/Open Font Format file can be packaged in WOFF format for Web use. anybody else see problems here. W3C its main goal is to open standards right ? No, I don't see a problem there. WOFF *is* an

Re: Gecko switched to use standard integer types

On 22/8/12 17:35, Ehsan Akhgari wrote: I just landed the patches in bug 579517 which switch all of the code in mozilla-central and comm-central [1] to use the standard integer types as opposed to NSPR integer types. Here's what this means to you: * If you're a developer, this will most likely