Lazy load fonts in a FontGroup
The first commit message explains this so I'll just copy it here:
---
This is a step towards fixing #17267. To fix that, we need to be able to
try various different fallback fonts in turn, which would become
unweildy with the prior eager-loading strategy.
Prior to this change, FontGroup loaded up all Font instances, including
the fallback font, before any of them were checked for the presence of
the glyphs we're trying to render.
So for the following CSS:
font-family: Helvetica, Arial;
The FontGroup would contain a Font instance for Helvetica, and a Font
instance for Arial, and a Font instance for the fallback font.
It may be that Helvetica contains glyphs for every character in the
document, and therefore Arial and the fallback font are not needed at
all.
This change makes the strategy lazy, so that we'll only create a Font
for Arial if we cannot find a glyph within Helvetica. I've also
substantially refactored the existing code in the process and added
some documentation along the way.
---
I've added some tests in the second commit, but it required quite a bit of gymnastics to make it possible to write such a test. I'm not sure if the added complexity to the production code is worth it?
On the other hand, having this infrastructure in place may be useful for testing future changes in this area, and also possibly brings us a step closer to extracting a library as discussed in #4901. (What I mean by that is: it reduces coupling between `FontCacheThread` and `FontContext` -- the latter would have a place in such a library, the former wouldn't.)
Source-Repo: https://github.com/servo/servo
Source-Revision: f48dce120dddd8e3d585cfc8bc221faa2726bf6b
Otherwise the log gets spammed with all the individual bytes of the
underlying font file.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0d00e9a6ad08a0a57484036e37f118912295326
style: Make all keywords CamelCase for consistency.
Source-Repo: https://github.com/servo/servo
Source-Revision: b24778202a4d886a990ee493adfb6851ac4be40c
Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1409255
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because testing is on the Gecko side.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4c538b642e4bdfbf42c522c5a59c258a6d14546e
<!-- Please describe your changes on the following line: -->
Automatically verify that derive() lists are alphabetically ordered #18172
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#18172 (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 474369618965569407d127b1e8c481e757cc59d3
It doesn't make much sense to store `font-weight` as separate enums, especially given that we would need to support (somehow) arbitrary font weight value when we implement CSS Fonts Level 4.
This PR refactors the `font-weight` a bit to make it store as `u16` directly.
Source-Repo: https://github.com/servo/servo
Source-Revision: f11a922760a08ffb956607d9ab447f8f2a319a25
hi there!
on windows, this change properly scales a font's line height by its size.
previously, line height was not scaled to the font's size at all, which meant line heights become worse and worse the further you scaled away from the font's design size (in either direction, larger or smaller).
this change makes the `line_gap` ratio and size scale with the font size. i've hand checked that the new computed `line_gap` matches the effective heights in chrome and firefox when `line-height = normal` for a bunch of system fonts. (servo's rendering quality on windows is a different story, though).
i believe this also solves #16476.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: 8fd7dc80c40440b88f42b8f1036ef67483dd93f0
I got a panic in Servo when I ran it with `RUST_LOG=debug`, which was due to `FT_Get_Postscript_Name` returning a null pointer.
I'm not sure how to add a test for this, so there is none right now.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 5ccb087769fdb5253514e1ea2babd28b21c65907
<!-- Please describe your changes on the following line: -->
This PR:
* updates the browserhtml dep (fixes https://github.com/servo/servo/issues/15255)
* updates the Windows font metric calculation (fixes https://github.com/servo/servo/issues/15698, based on codec-abc https://github.com/servo/servo/pull/15937#issuecomment-286513712)
* may address https://github.com/servo/servo/issues/15933. With this PR, I was not able to repro
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because change are to UI/visual results of font drawing
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: cea1760eb7689d88b18525fac7d53f9a12fdb8a1
This PR implements downloadable font support for Servo. It depends on new changes in webrender and dwrote, and adds a dependency on the `truetype` crate for pulling out basic font information. The original DirectWrite API does not provide an easy way to query font information direct from a `FontFace` (which is what you create from a `FontFile`). There are new DirectWrite APIs starting with Windows 10 that allow for this, but they are Win 10+ only, and `winapi-rs` does not yet have bindings for those versions of the interfaces (specificially, `IDirectWriteFontFace3`). The way to do this with DW is to go through a lot of pain in creating a custom collection and enumerator, add your font to your custom collection, then query the collection for its properties.
Instead, we just parse the truetype tables directly to pull out the few bits of information that we need. The `truetype` crate is ok, but I discovered some bugs (an update needs to get pushed to crates.io before this will build). It might be more worthwhile to just implement the tiny bit of truetype parsing that we need ourselves in Servo.
I'm guessing there are existing tests for downloadable fonts...
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 1a7404e38c0f0e9c58487299956bec78589191c7
<!-- Please describe your changes on the following line: -->
This PR adds support for DirectWrite text rendering using a thin wrapper for dwrite, as well as similar functionality added to WebRender. In doing so it removes the FreeType dep from the Windows build.
There is still work to be done here, but this is a good starting point for future cleanup and fixes.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [X] These changes fix#13371 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they are already tested by other tests
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 796fae4bbe966a4e6e32b01fa44f6123c7162992
Previously, `string-cache` defined:
* An string-like `Atom` type,
* An `atom!("foo")` macro that expands to a value of that type, for a set of strings known at compile-time,
* A `struct Namespace(Atom);` type
* A `ns!(html)` macro that maps known prefixed to `Namespace` values with the corresponding namespace URL.
Adding a string to the static set required making a change to the `string-cache` crate.
With 0.3, the `Atom` type is now generic, with a type parameter that provides a set of static strings. We can have multiple such sets, defined in different crates. The `string_cache_codegen` crate, to be used in build scripts, generates code that defines such a set, a new atom type (a type alias for `Atom<_>` with the type parameter set), and an `atom!`-like macro.
The html5ever repository has a new `html5ever_atoms` crate that defines three such types: `Prefix`, `Namespace`, and `LocalName` (with respective `namespace_prefix!`, `namespace_url!`, and `local_name!` macros). It also defines the `ns!` macro like before.
This repository has a new `servo_atoms` crate in `components/atoms` that, for now, defines a single `Atom` type (and `atom!`) macro. (`servo_atoms::Atom` is defined as something like `type Atom = string_cache::Atom<ServoStaticStringSet>;`, so overall there’s now two types named `Atom`.)
In this PR, `servo_atoms::Atom` is used for everything else that was `string_cache::Atom` before. But more atom types can be defined as needed. Two reasons to do this are to auto-generate the set of static strings (I’m planning to do this for CSS property names, which is the motivation for this change), or to have the type system help us avoid mix up unrelated things (this is why we had a `Namespace` type ever before this change).
Introducing new types helped me find a bug: when creating a new attribute `dom::Element::set_style_attr`, would pass `Some(atom!("style"))` instead of `None` (now `Option<html5ever_atoms::Prefix>` instead of `Option<string_cache::Atom>`) to the `prefix` argument of `Attr::new`. I suppose the author of that code confused it with the `local_name` argument.
---
Note that Stylo is not affected by any of this. The `gecko_string_cache` module is unchanged, with a single `Atom` type. The `style` crate conditionally compiles `Prefix` and `LocalName` re-exports for that are both `gecko_string_cache::Atom` on stylo.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 5b4cc9568dbd5c15e5d2fbc62719172f11566ffa
This uses a (very simple) Win32 API call to enumerate font
families available, and load them as byte buffers.
The font rasterization itself is done by freetype.
This gets Servo + WR + Windows working, but should be improved
by adding a proper implementation that matches fonts correctly
and also uses DirectWrite (or GDI) to handle font rasterization.
Source-Repo: https://github.com/servo/servo
Source-Revision: eb3333eb2f6dbac75ecf23e84cbb12149b3dc969
