Re: [webkit-dev] Request For Position on CSS containment

2021-03-15 Thread Rob Buis via webkit-dev
I misread "WebKit supports CSS containment." as "WebKit supports CSS 
containment already". Sorry for the noise!


Regards,

Rob.

Am 15.03.21 um 21:35 schrieb Simon Fraser:

We have no code for css containment yet.

Simon



On Mar 15, 2021, at 12:57 PM, Rob Buis  wrote:

Hi,

If true, then https://bugs.webkit.org/show_bug.cgi?id=172026 can be closed.

I am finding the feature in features.json, but I am not sure that means there 
is actual code.

There may be code in RenderLayerBacking, but AFAIU that would mean "only" 
contain: paint and would not be WebExposed? Can somebody check?

Regards,

Rob.

Am 15.03.21 um 20:18 schrieb Simon Fraser:

WebKit supports CSS containment.

Simon


On Mar 15, 2021, at 9:14 AM, Rob Buis via webkit-dev 
 wrote:

Hi webkit-dev,

This is a request for WebKit's position on CSS containment.

Our first interest is to implement the contain property as specified here:
https://www.w3.org/TR/css-contain-1/

After that, we want to work on style containment and the content-visibility 
property:
https://www.w3.org/TR/css-contain-2/
Regards,

Cathie and Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request For Position on CSS containment

2021-03-15 Thread Rob Buis via webkit-dev

Hi,

If true, then https://bugs.webkit.org/show_bug.cgi?id=172026 can be closed.

I am finding the feature in features.json, but I am not sure that means 
there is actual code.


There may be code in RenderLayerBacking, but AFAIU that would mean 
"only" contain: paint and would not be WebExposed? Can somebody check?


Regards,

Rob.

Am 15.03.21 um 20:18 schrieb Simon Fraser:

WebKit supports CSS containment.

Simon


On Mar 15, 2021, at 9:14 AM, Rob Buis via webkit-dev 
 wrote:

Hi webkit-dev,

This is a request for WebKit's position on CSS containment.

Our first interest is to implement the contain property as specified here:
https://www.w3.org/TR/css-contain-1/

After that, we want to work on style containment and the content-visibility 
property:
https://www.w3.org/TR/css-contain-2/
Regards,

Cathie and Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request For Position on CSS containment

2021-03-15 Thread Rob Buis via webkit-dev

Hi webkit-dev,

This is a request for WebKit's position on CSS containment.

Our first interest is to implement the contain property as specified here:
https://www.w3.org/TR/css-contain-1/

After that, we want to work on style containment and the 
content-visibility property:

https://www.w3.org/TR/css-contain-2/
Regards,

Cathie and Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position on the aspect-ratio CSS property

2020-10-30 Thread Rob Buis
Personally I am in favor of removing -webit-aspect-ratio, however I 
think -webit-aspect-ratio: from-intrinsic and 
-webit-aspect-ratio:from-dimensions do have some effect when looking at 
the code. Does anybody know if it is actually used out there? Do we need 
to keep it? Maybe Dean Jackson knows?


Regards,

Rob.

Am 29.10.20 um 22:23 schrieb Jen Simmons:
I’ve talked to some folks here, poked around, and we believe it’s 
probably fine for `aspect-ratio` to override `-webkit-aspect` ratio.


It looks like Chromium removed `-webkit-aspect`  in 2014 because the 
"property is parsed and stored on RenderStyle, but it's not used 
anywhere, i.e. it has no effect.” 
https://codereview.chromium.org/647723002 



I don’t see any Author-facing feature here. There's nothing about it 
on CSS Tricks, nothing on MDN. My demo does nothing. Looks like 
aspectRatioNumerator and aspectRatioDenominator appear to be unused.


Jen

Jen Simmons
Web Technology Evangelist
Apple, Inc.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position on Event Timing

2020-10-22 Thread Rob Buis

Hi Ryosuke, Simon,

Have the raised concerns been addressed now, given the document shared 
by Nicolás and github issue discussions? I would like to avoid bitrot 
for my prototype :)


Regards,

Rob.

Am 30.09.20 um 00:10 schrieb Nicolás Peña Moreno:
I've written a doc to explain our perspective on the use-cases of 
these two APIs: 
https://docs.google.com/document/d/1UrPQD0lOhHKgQy1oy1Cs0F9AsBb83q_bx8cAvu_sKrI 
<https://docs.google.com/document/d/1UrPQD0lOhHKgQy1oy1Cs0F9AsBb83q_bx8cAvu_sKrI>.



On Tue, Sep 29, 2020 at 5:16 PM Yoav Weiss <mailto:y...@yoav.ws>> wrote:


+Nicolás Peña <mailto:n...@chromium.org>

On Sun, Aug 9, 2020 at 5:40 AM Ryosuke Niwa mailto:rn...@webkit.org>> wrote:

On Fri, Aug 7, 2020 at 2:09 PM Rob Buis mailto:rb...@igalia.com>> wrote:
>
> I was not aware of Long Tasks API. However it seems to have
a slightly
> different focus (task vs. input events). Also I am mostly
interested in
> First Input Delay, and it was decided some time ago to not
put it in
> Long Tasks API (see
>

https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#

<https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#>).

The concern still withstands. We don't have dozens of slightly
different APIs that websites need to track for junks & delays
during
user interactions.

It's also unclear how this first input delay works with a
single page
app which may have multiple transitions after a single page
load from
the browser engine's perspective. There had been some discussions
about this in the past in Web Perf WG but I don't think we've
come to
any conclusion about it.

In general, I'm hesitant to have any of these APIs implemented in
WebKit without figuring out more coherent picture of how
they'd all
fit together to address underlying use cases.

- R. Niwa

> On 06.08.20 20:07, Simon Fraser wrote:
> > Our feedback is that this API seems reasonable, but that
there's overlap with the "long tasks" API,
> > and it's not clear if we need both.
    > >
> > Simon
> >
> >> On Aug 6, 2020, at 10:43 AM, Rob Buis mailto:rb...@igalia.com>> wrote:
> >>
> >> Hi Webkit-Dev,
> >>
> >> I would like to get an official position from Webkit on
the Event Timing Web Perf API.
> >> Besides providing information about input event latency
it can be used to obtain
> >> First Input Timing metrics. This specification builds on
the Performance Timeline
> >> specification, which is implemented in Webkit. Chrome has
implemented the Event
> >> Timing API, see the chrome status entry below.
> >>
> >> - Specification: https://wicg.github.io/event-timing/
<https://wicg.github.io/event-timing/>
> >> - Explainer: https://github.com/WICG/event-timing
<https://github.com/WICG/event-timing>
> >> - MDN:
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming

<https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming>
> >> - ChromeStatus:
https://chromestatus.com/feature/5167290693713920
<https://chromestatus.com/feature/5167290693713920>
> >> - Caniuse.com URL:
https://caniuse.com/#feat=mdn-api_performanceeventtiming
<https://caniuse.com/#feat=mdn-api_performanceeventtiming>
> >>
> >> Regards,
> >>
> >> Rob.
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
<mailto:webkit-dev@lists.webkit.org>
> >> https://lists.webkit.org/mailman/listinfo/webkit-dev
<https://lists.webkit.org/mailman/listinfo/webkit-dev>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev
<https://lists.webkit.org/mailman/listinfo/webkit-dev>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev
<https://lists.webkit.org/mailman/listinfo/webkit-dev>

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position on the aspect-ratio CSS property

2020-10-20 Thread Rob Buis

Hi,

I was looking into aspect-ratio and there is one thing Christian did not 
mention yet. There is an existing aspect-ratio implementation 
(https://bugs.webkit.org/show_bug.cgi?id=47738) that uses the property 
-webkit-aspect-ratio and seems replaced elements only. Probably 
aspect-ratio can override -webkit-aspect-ratio, anyway since this may 
influence the position I thought I should mention it.


Cheers,

Rob.

>Hello,

>I'd like to request an official position the aspect-ratio CSS
>property, as both Gecko and Blink are currently implementing it, and
>ideally we'd like to ship it soonish.

>https://drafts.csswg.org/css-sizing-4/#aspect-ratio

>https://docs.google.com/document/d/1VqD0mfkIDyCxQBrrvDw5wEbhXBsmEYIhk6ahiX_fvco/edit#

>Thanks,
>Christian

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position on Event Timing

2020-08-07 Thread Rob Buis
I was not aware of Long Tasks API. However it seems to have a slightly 
different focus (task vs. input events). Also I am mostly interested in 
First Input Delay, and it was decided some time ago to not put it in 
Long Tasks API (see 
https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#).


Regards,

Rob.

On 06.08.20 20:07, Simon Fraser wrote:

Our feedback is that this API seems reasonable, but that there's overlap with the 
"long tasks" API,
and it's not clear if we need both.

Simon


On Aug 6, 2020, at 10:43 AM, Rob Buis  wrote:

Hi Webkit-Dev,

I would like to get an official position from Webkit on the Event Timing Web 
Perf API.
Besides providing information about input event latency it can be used to obtain
First Input Timing metrics. This specification builds on the Performance 
Timeline
specification, which is implemented in Webkit. Chrome has implemented the Event
Timing API, see the chrome status entry below.

- Specification: https://wicg.github.io/event-timing/
- Explainer: https://github.com/WICG/event-timing
- MDN: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming
- ChromeStatus: https://chromestatus.com/feature/5167290693713920
- Caniuse.com URL: https://caniuse.com/#feat=mdn-api_performanceeventtiming

Regards,

Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position on Event Timing

2020-08-06 Thread Rob Buis

Hi Webkit-Dev,

I would like to get an official position from Webkit on the Event Timing 
Web Perf API.
Besides providing information about input event latency it can be used 
to obtain
First Input Timing metrics. This specification builds on the Performance 
Timeline
specification, which is implemented in Webkit. Chrome has implemented 
the Event

Timing API, see the chrome status entry below.

- Specification: https://wicg.github.io/event-timing/
- Explainer: https://github.com/WICG/event-timing
- MDN: 
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming

- ChromeStatus: https://chromestatus.com/feature/5167290693713920
- Caniuse.com URL: https://caniuse.com/#feat=mdn-api_performanceeventtiming

Regards,

Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Lazy loading

2019-10-28 Thread Rob Buis

Regarding lazily loading CSS background images, Chromium determines whether
or not to lazily load CSS background images according to the default lazy
loading behavior, and isn't directly controlled by the "loading" attribute.
There are some heuristics involved, e.g. background images inside an iframe
that was itself lazily loaded are loaded eagerly for performance reasons,
but those heuristics are just part of the default lazy loading behavior.


Scott, thanks for the clarification! Are there plans to better specify 
CSS background images lazy loading?


Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Lazy loading

2019-10-28 Thread Rob Buis
Apologies, it seems I spread some misinformation about CSS background 
lazy loading, which Scott rectified.


On 10/29/19 12:36 AM, Maciej Stachowiak wrote:




On Oct 28, 2019, at 3:08 PM, Rob Buis  wrote:

On 10/28/19 9:07 PM, Maciej Stachowiak wrote:


Yet another possible task is making lazy loading work for CSS backgrounds, this 
is implemented in the prototype but I don't think there are many tests for it.

Is there a way for content authors to opt in/out (depending on the default), or 
does this just always follow what the default lazy loading setting is?

 From reading the chromium code, it seems to use a combination of feature 
policy and the loading attribute to decide whether to enable CSS backgrounds 
lazy loading or not. Hopefully a chromium developer can confirm.

- I couldn’t find a spec for a lazy loading feature policy either, and the 
Chrome Platform Status page for it gives the status as “removed”[2] so this too 
might be a nonstandard thing. Or maybe there is a newer  (Doesn’t look like the 
feature policy aspect is in your patch though.)
The prototype was done in February. I think Youenn was starting 
implementation of feature policy at the same time or maybe later. Then 
later I did not really touch CSS background lazy loading again, since 
there were a lot of other issues instead to address, one of them being 
the spec was changing over time. Will be happy with addressing it now, 
though I am not sure how impactful it will be for users compared to lazy 
image loading.

I hope I am not being too nitpicky. I do think this is a great feature. I just 
want to make sure we’re cautious about the line between implementing 
standards-track stuff vs copying things from Chromium that are nonstandard or 
unspecified (so far).


Understood.

Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Lazy loading

2019-10-28 Thread Rob Buis

On 10/28/19 9:07 PM, Maciej Stachowiak wrote:


Yet another possible task is making lazy loading work for CSS backgrounds, this 
is implemented in the prototype but I don't think there are many tests for it.

Is there a way for content authors to opt in/out (depending on the default), or 
does this just always follow what the default lazy loading setting is?


From reading the chromium code, it seems to use a combination of 
feature policy and the loading attribute to decide whether to enable CSS 
backgrounds lazy loading or not. Hopefully a chromium developer can confirm.


Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Lazy loading

2019-10-28 Thread Rob Buis

Hi,

I made a lazy image loading prototype earlier this year 
(https://bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting 
it up into reviewable patches. The main implementation part landed 
recently so I am wondering about the next steps.


One thing left to do for sure is cleaning up/adding tests. For one there 
are tests in http/tests/lazyload which can just be WPT tests, so I'll 
work in this area for sure. As usual, while adding new tests bugs may 
show up and more patches will be needed.


Another possible task is implementing metadata fetch, but it makes the 
code more complex and chromium has backtracked from it.


Changing the behavior of loading=auto to make lazy loading the default 
seems risky and should possibly only be done when lazy image loading is 
deemed stable enough.


Yet another possible task is making lazy loading work for CSS 
backgrounds, this is implemented in the prototype but I don't think 
there are many tests for it.


A related task is implementing lazy loading for iframe's, I took a quick 
look and this looks like similar work to lazy image loading, but should 
be much easier to implement now the building blocks are there.


Finally there is the task of setting threshold viewport distance values 
for triggering deferred loads. I only have access to iOS simulator, so I 
wonder if that is something Apple could help with?


I do not have a strong preference among these tasks. Thoughts?
Cheers,

Rob.

P.S: I intend to attend the WebKit Contributors meeting, so feel free to 
chat with me there about lazy loading.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Catalina and Xcode setup problems

2019-09-02 Thread Rob Buis

Hi,

I recently tried Catalina beta 7 and Xcode 11.0 beta 7 and ran into some 
problems. When running
mini-browser loading fails in WK2 (works for WK1) with the following 
Inspector message:
Failed to load resource: A server with the specified hostname could not 
be found.


Also many loading related tests fail or timeout.

Did anybody try a similar setup or can tell if I missed a setup step? 
Could it be a sandbox issue and/or is Python 2 or 3 choice important?

Cheers,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Referrer policy attribute on iframe's

2019-02-28 Thread Rob Buis

Hi,

I have a patch up for referrer policy attribute support on iframe's:

https://bugs.webkit.org/show_bug.cgi?id=179053

Any takers?

Cheers,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] XML Serialization Issues

2013-08-29 Thread Rob Buis
Fixed.

More seriously, all bugs mentioned below are fixed/closed, please open
new ones for any regressions/improvements.
Cheers,

Rob.

On 19 June 2013 14:44, Alex Milowski a...@milowski.com wrote:
 I was working on using MathJax [1] to turn MathML into SVG and ran into some
 serious serialization issues.  In summary, as MathJax programmatically
 creates SVG renderings of the MathML, when it creates XLink attributes, it
 doesn't seem to define a prefix.  While this works for rendering, it does
 when you try to extract a serialization of the SVG.

 That is, MathJax creates SVG 'use' elements like (assuming SVG as the
 default namespace):

 use xlink:href=#MJMATHI-78 xmlns:xlink=http://www.w3.org/1999/xlink/

 but instead I get:

 use href=#MJMATHI-78 xmlns=http://www.w3.org/1999/xlink/

 which makes the SVG incorrect as the 'use' element is now in the xlink
 namespace.

 You can work around this by manually setting the prefix property on each
 xlink:href attribute.

 Looking into why this happens, I can see that the serializer seriously
 broken in a number of ways when the DOM is constructed with incomplete (e.g.
 missing namespace declarations) or inconsistent information (e.g. same
 prefix used for different namespaces in the same context).

 I found at least 6 bugs outstanding (#16739 [2], #16496 [3], #19121 [4],
 #22958 [5], #83056 [6], #106531 [7]) and filed a new one (#117764 [8]).
 Some of these date back to 2007 (6 years ago!).

 These bugs break down to these categories:

 1. Default namespace issues: #16739, #106531, #16496
 2. Conflicting prefix mappings: #117764, #19121
 3. Namespace attribute issues: #22958, #83056, #117764

 In looking at the code (MarkupAccumulator.cpp), they all suffer from one of
 two problems:

 1. The computed prefix used isn't properly used for the declaration.

 2. The generated namespace mappings aren't properly stored, scoped, or dealt
 with when they are inconsistent.

 There is an general assumption in the code that certain prefixes should
 always be used for certain namespaces.  Unfortunately, it does so without
 looking to see whether there is a conflict already in scope.  Also, when the
 namespace is not recognized and there is no prefix, a prefix needs to be
 generated for the serialization.

 Having written several robust XML Serializers for other projects, this can
 all be fixed in a straightforward way.  I've looked at the code and know
 what should be done.  The changes are probably modest.

 Unfortunately, I can't spend the time to directly write and test the code
 till probably after November.  :(

 I am certainly willing to help, explain my strategy, advise, test, etc. if
 there was another willing developer out there who would like to see these
 bugs closed.

 [1] http://www.mathjax.org/
 [2] https://bugs.webkit.org/show_bug.cgi?id=16739
 [3] https://bugs.webkit.org/show_bug.cgi?id=16496
 [4] https://bugs.webkit.org/show_bug.cgi?id=19121
 [5] https://bugs.webkit.org/show_bug.cgi?id=22958
 [6] https://bugs.webkit.org/show_bug.cgi?id=83056
 [7] https://bugs.webkit.org/show_bug.cgi?id=106531
 [8] https://bugs.webkit.org/show_bug.cgi?id=117764


 --
 --Alex Milowski
 The excellence of grammar as a guide is proportional to the paucity of the
 inflexions, i.e. to the degree of analysis effected by the language
 considered.

 Bertrand Russell in a footnote of Principles of Mathematics

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Slow idioms with WTF::String

2011-07-12 Thread Rob Buis
Hi Yong,

On 12 July 2011 18:10, Yong Li yong.li.web...@gmail.com wrote:
 Another slow case is converting a const C string to WTF::String every
 time. For example,

    return (m_httpHeaderFields.contains(If-Match) ||
            m_httpHeaderFields.contains(If-Modified-Since) ||
            m_httpHeaderFields.contains(If-None-Match) ||
            m_httpHeaderFields.contains(If-Range) ||
            m_httpHeaderFields.contains(If-Unmodified-Since));

 This function creates 5 Strings (calls fastMalloc 5 times), and also
 calculates the hash key 5 times, and then throws them away.

In this case, the code already indicates it is not optimal:

HTTPHeaderMap.h:
// Alternate accessors that are faster than converting the char* to
AtomicString first.
bool contains(const char*) const;

Also this converting can probably be fixed by using
DEFINE_STATIC_LOCAL(AtomicString,...).
Cheers,

Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Writing a new XML parser with no external libraries

2011-06-29 Thread Rob Buis
On 29 June 2011 01:10, Dirk Schulze k...@webkit.org wrote:

 Am 29.06.2011 um 05:42 schrieb TAMURA, Kent:

 I'm a little negative of developing a new XML parser. I'm afraid that the 
 new parser introduces a lot of security/stability problems which existing 
 parsers already resolved.

 I feel the same. Writing a new parser from scratch means introducing a lot of 
 new security bugs, parsing errors and maybe bigger performance lost at the 
 beginning. Speaking from the SVG side, we fail at least three tests on the 
 W3C SVG Test Suite because of parsing bugs if libxml2 on MacOS. All of these 
 bugs are fixed in later versions of libxml2. Updating libxml2 more often on 
 MacOS would help a lot.

Specifically these test failures are due to a bug with internal
entities in libxml2 which was first seen with OS X 10.5.8, so before
that it worked. Maybe a new libxml2 version is used in Lion and will
fix it, but should a new XML parser come about entities are an area
that should work even though little SVG files out there actually seem
to use it in practice.
Cheers,

Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] SVG font file location

2011-05-25 Thread Rob Buis
Hi Saba,

On 25 May 2011 16:08, Saba Taseer stehs...@hotmail.com wrote:
 I am trying to study SVG fonts rendering in webkit. I followed the
 instructions at http://frabru.de/c.php/article/SVGFonts-usage and got my SVG
 font running for Chrome. I added the same script as a string in winlauncher
 to see the course of events SVG text goes through to render SVG text, but
 the text displays in sans-serif and not in Tomson Talks font. I have
 copied TomsonTalks.svg file in winLauncher folder. I tried giving the
 absolute path to the font file too but it still doesnt work. Please let me
 know where should I put my svg font file for winlauncher application. Here
 is the script I am using
 ?xml version=1.0 encoding=UTF-8?
 svg xmlns=http://www.w3.org/2000/svg;
 xmlns:xlink=http://www.w3.org/1999/xlink; viewBox=0 0 400 300
 defs 
 font-face font-family=Tomson Talks
   font-face-src
 font-face-uri xlink:href=TomsonTalks.svg#TomsonTalks
     font-face-format string=svg/
    /font-face-uri
   /font-face-src
  /font-face
 /defs
  text font-family='Tomson Talks',sans-serif font-size=25hello
   tspan x=302 y=60 text-anchor=middleYou cause/tspan
  /text
 /svg

 I am not good at scripting, plz help me if I have done smthing wrong in the
 script.

If TomsonTalks.svg is in the same dir as the listed svg I think it
should work. You can try removing the spaces in the name as well, I
think it looks valid how you did it but maybe there is a bug there.
Finally, as a sanity check you could try
LayoutTests/svg/custom/glyph-transformation-with-hkern.svg as a SVG
font test that should work. If you don't have source checkout you can
get it here:

http://svn.webkit.org/repository/webkit/trunk/LayoutTests/svg/custom/
Cheers,

Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] SVG Fonts in webkit

2011-05-24 Thread Rob Buis
Hello Saba,

On 24 May 2011 17:16, Saba Taseer stehs...@hotmail.com wrote:
 I was trying to study fonts rendering in Webkit. I was successfully able to
 see the path html text tag follows to be drawn in inlinetextbox.cpp. Then I
 tried to study SVG fonts rendering in webkit, but I didnot reach any of
 SVGFont element related calls. Can some one please explain how SVG fonts are
 handled in Webkit? I have ENABLE_SVG switch enabled in my webkit, do I have
 to enable SVG fonts seperately?

You can find the code by grepping in Source/WebCore for SVG_FONTS.
AFAIK it is disabled when SVG is enabled. Hope that helps!
Cheers,

Rob.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev