Pull a thread, and end up removing logs of old fontmgr code.
Change-Id: I73cebf9c011a99e9d12fd728e8677fcb0700407f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/429338
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This relands the idea that onMatchFaceStyle is no longer used, but
leaves the baseclass virtual to stage removing it from client
subclasses.
This reverts commit 3c04a65508.
Change-Id: I18570065249c86f7f155c28288dce3ea9d59f619
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401759
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Mechanically updated via Xcode "Replace Regular Expression":
typedef (.*) INHERITED;
-->
using INHERITED = $1;
The ClangTidy approach generated an even larger CL which would have
required a significant amount of hand-tweaking to be usable.
Change-Id: I671dc9d9efdf6d60151325c8d4d13fad7e10a15b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314999
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This belongs on a SkTypeface which might have a back pointer to a font
collection in which it can do lookup. It makes little sense to pass a
random typeface into a potentially incompatible SkFontMgr. Some of the
existing implementations will crash if this happens.
This initial commit is 'conservative' in that it removes the public API,
the backing onMatchFaceStyle is left intact to avoid breaking
implementors (as opposed to users). It may also be used as an
implementation detail in a future SkTypeface API when the typeface holds
a reference on its collection.
It appears there are no users of this API and it is also untested.
Change-Id: I6e06f918ad73a500c254746b3957c3579fab3b9c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299198
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Ensure that it always exists and that implementers don't forget about it
and wind up with an incorrect default.
Change-Id: I383cb1eb8e15de49fbbb007d719837804aca33af
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299456
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
The current documentation states that SkFontMgr::matchFamilyStyle will
never return nullptr, resolving to the default system font or the empty
typeface if necessary. This isn't the behavior desired by any users,
since doing so makes it difficult for the user to check if a 'good'
match was made or not. All of the current SkFontMgr implementations can
return nullptr anyway for a number of reasons, from lack of a 'good'
match to an error.
Bug: skia:8260
Change-Id: I96299c16aaa7228fd42a9d8ec4889c7355cb53a5
Reviewed-on: https://skia-review.googlesource.com/147721
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Change-Id: Idad3c8b6961bb617afedb8e353060b9044edaee3
Reviewed-on: https://skia-review.googlesource.com/136066
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Auto-Submit: Hal Canary <halcanary@google.com>
