All of the text run methods use character indices and the split_to_width function also uses character indices. Therefore it will be easier to use character indices to keep track of line breaks than glyph indices.
If msttcorefonts isn't installed, output a more informative error message.
./servo ../src/test/html/about-mozilla.html prints
"task 'LayoutWorker' failed at 'No matching font(s), are the appropriate fonts installed?',
../servo/src/components/gfx/font_context.rs:195"
vs.
"task 'LayoutWorker' failed at 'assertion failed: fonts.len() > 0',
../servo/src/components/gfx/font_context.rs:195"
Before we had Vec<T>, Option<~[T]> was used as an optimization of ~[T] to avoid allocating for empty vectors when that was the common case. Vec<T> itself does this optimization, so there is no need for this anymore.
r? @larsbergstrom
Before we had Vec<T>, Option<~[T]> was used as an optimization of ~[T]
to avoid allocating for empty vectors when that was the common case.
Vec<T> itself does this optimization, so there is no need for this anymore.
This moves all the handling of optional arguments into `CGArgumentConverter`, and leaves `instantiateJSToNativeConversionTemplate` to only deal with the declaration of stack variables.
Implementing the CSSOM requires giving the script task access to the
computed style for a node. Moving it into a new SharedLayoutData struct
member of LayoutDataRef seems to be the best way to achieve this.
This is the first step towards #1721.
Right now, the load is kicked off inside the parser glue. This is unfortunate
for several reasons:
1) we'd like to replace the current parser (libhubbub) by our own parser,
written in Rust, so code intertwined with the parser will have to be
rewritten;
2) it is impossible to support dynamically (i.e. from script) created iframes
in this way;
3) the code flow around loading subdocuments is complicated needlessly.
This commit adds the constellation channel (on which the message to actually
load the document is sent) as a field on the Page, to allow HTMLIFrameElement
to access it.
In rewriting the code, support for dynamically created iframes is added, and
a task failure is avoided when the value of the src attribute can not be
parsed.
Right now, the load is kicked off inside the parser glue. This is unfortunate
for several reasons:
1) we'd like to replace the current parser (libhubbub) by our own parser,
written in Rust, so code intertwined with the parser will have to be
rewritten;
2) it is impossible to support dynamically (i.e. from script) created iframes
in this way;
3) the code flow around loading subdocuments is complicated needlessly.
This commit adds the constellation channel (on which the message to actually
load the document is sent) as a field on the Page, to allow HTMLIFrameElement
to access it.
In rewriting the code, support for dynamically created iframes is added, and
a task failure is avoided when the value of the src attribute can not be
parsed.
