This allows us to avoid instantiating separate gfxFont objects when content is tagged
with different 'lang' attributes, yet ends up using the same fonts (e.g. Wikipedia may
use a default font such as Arial for language names/links that are tagged with several
dozen different languages).
Differential Revision: https://phabricator.services.mozilla.com/D96978
This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
This replaces and extends the "hidden" flag we currently use on macOS to mark internal system fonts
like .LastResort and .Keyboard that should not be exposed; rather than just a boolean "hidden" flag
we'll have several levels of visibility, some of which the user may opt in to exposing (at the cost
of potentially becoming more fingerprintable).
The current patch assumes three levels besides always-hidden:
Base - fonts that are part of the base OS install and always available
LangPack - fonts that are provided by the OS subject to user's chosen language options
User - user-installed fonts that were not provided by the OS
(This categorization may be subject to revision as we learn more about real-world needs and
configurations.)
Differential Revision: https://phabricator.services.mozilla.com/D66124
--HG--
extra : moz-landing-system : lando
This replaces and extends the "hidden" flag we currently use on macOS to mark internal system fonts
like .LastResort and .Keyboard that should not be exposed; rather than just a boolean "hidden" flag
we'll have several levels of visibility, some of which the user may opt in to exposing (at the cost
of potentially becoming more fingerprintable).
The current patch assumes three levels besides always-hidden:
Base - fonts that are part of the base OS install and always available
LangPack - fonts that are provided by the OS subject to user's chosen language options
User - user-installed fonts that were not provided by the OS
(This categorization may be subject to revision as we learn more about real-world needs and
configurations.)
Differential Revision: https://phabricator.services.mozilla.com/D66124
--HG--
extra : moz-landing-system : lando
This removes a lot of old cruft in thebes to instantiate Cairo scaled fonts.
Instead, we only instantiate the Cairo scaled font inside Moz2D when we actually
need it for DrawTargetCairo. This thus gets rid of the duplicated code we had
inside both Moz2D and thebes to deal with Cairo scaled fonts.
Differential Revision: https://phabricator.services.mozilla.com/D47297
--HG--
extra : moz-landing-system : lando
Also ensure we consistently use the original-case family name in FontNameCache entries,
and only lowercase it to a "key" for lookup/insertion into the font list. This avoids
failures in test_font_whitelist.html due to inconsistency in whether family names have
been lowercased.
Differential Revision: https://phabricator.services.mozilla.com/D36112
--HG--
extra : moz-landing-system : lando
This is the main part of the implementation, except that it doesn't handle populating the
local names table (for @font-face src:local() lookups) with Full and PostScript names;
that follows in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D36110
--HG--
extra : moz-landing-system : lando
I'll need to add a couple of extra fields to the cache records, and realized that the current format
looks really fragile; in theory, it'd break if a font name ever contained a comma or semicolon
(unlikely though that may be). So let's fix it to be a bit more robust before we add to it further.
Using control characters from the C0 range to delimit fields/records, instead of ASCII punctuation,
removes the (tiny) risk of conflict with characters that actually occur in a name, and using
distinct field and record separators means that we can better check that the records we're loading
from the cache actually match the expected format.
(Given that the startup cache gets re-created when the build ID is updated, a change in the format
between versions wasn't going to cause problems for users; their old cache just gets blown away
when upgrading. Still, a little more robustness seems like a good thing.)
Differential Revision: https://phabricator.services.mozilla.com/D36109
--HG--
extra : moz-landing-system : lando
And with this, all tests pass on tryserver when the shared list is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D36112
--HG--
extra : moz-landing-system : lando
This is the main part of the implementation, except that it doesn't handle populating the
local names table (for @font-face src:local() lookups) with Full and PostScript names;
that follows in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D36110
--HG--
extra : moz-landing-system : lando
I'll need to add a couple of extra fields to the cache records, and realized that the current format
looks really fragile; in theory, it'd break if a font name ever contained a comma or semicolon
(unlikely though that may be). So let's fix it to be a bit more robust before we add to it further.
Using control characters from the C0 range to delimit fields/records, instead of ASCII punctuation,
removes the (tiny) risk of conflict with characters that actually occur in a name, and using
distinct field and record separators means that we can better check that the records we're loading
from the cache actually match the expected format.
(Given that the startup cache gets re-created when the build ID is updated, a change in the format
between versions wasn't going to cause problems for users; their old cache just gets blown away
when upgrading. Still, a little more robustness seems like a good thing.)
Differential Revision: https://phabricator.services.mozilla.com/D36109
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
This rearranges how synthetic-bold use is determined in the font selection
& rendering code. Previously, we would decide during the font-selection
algorithm whether we need to apply synthetic-bold to the chosen face, and
then pass that decision through the fontgroup (storing it in the FamilyFace
entries of the mFonts array there) down to the actual rendering code that
instantiates fonts from the faces (font entries) we've selected.
That became a problem for variation fonts because in the case of a user
font, we may not have downloaded the resource yet, so we just have a "user
font container" entry, which carries the descriptors from the @font-face
rule and will fetch the actual resource when needed. But in the case of a
@font-face rule without a weight descriptor, we don't actually know at
font-selection time whether the face will support "true" bold (via a
variation axis) or not, so we can't reliably make the right decision about
applying synthetic bold.
So we now defer that decision until we actually instantiate a platform font
object to shape/measure/draw text. At that point, we have the requested
style and we also have the real font resource, so we can easily determine
whether fake-bold is required.
(This patch should not result in any visible behavior change; that will
come in a second patch now that the architecture supports it.)