ui/gfx/vector_icons/system_tray_battery.1x.icon - Issue 2099983002: Tweak Ash material design battery vector icons

Side by Side Diff: ui/gfx/vector_icons/system_tray_battery.1x.icon

Issue 2099983002: Tweak Ash material design battery vector icons (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Created 4 years, 5 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
1 // Copyright 2016 The Chromium Authors. All rights reserved.	1 // Copyright 2016 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

5 CANVAS_DIMENSIONS, 16,	5 CANVAS_DIMENSIONS, 16,

6 MOVE_TO, 5, 3.96f,	6 MOVE_TO, 5, 3,

7 CUBIC_TO, 5, 3.43f, 5.45f, 3, 6, 3,	7 R_H_LINE_TO, 5.99f,
	Evan Stade 2016/06/27 15:10:36 aside: I wonder if this really should be 6. The sk aside: I wonder if this really should be 6. The skiafy script already rounds to the nearest hundredth. Maybe we should be rounding to the nearest 50th? 10th? tdanderson 2016/06/27 17:23:59 From examining a random sample of icons on go/icon Show quoted text On 2016/06/27 15:10:36, Evan Stade wrote: > aside: I wonder if this really should be 6. The skiafy script already rounds to > the nearest hundredth. Maybe we should be rounding to the nearest 50th? 10th? From examining a random sample of icons on go/icons, two decimal places of precision (where the last digit can be even or odd) looks to be the norm. I don't really see much advantage of changing the rounding logic, and doing so will have the effect of changing the literals provided by these SVGs in ways that could (potentially) cause incorrect rendering of the icon. Evan Stade 2016/06/27 22:41:14 Yes, that would be because the skiafy tool rounds Show quoted text On 2016/06/27 17:23:59, tdanderson wrote: > On 2016/06/27 15:10:36, Evan Stade wrote: > > aside: I wonder if this really should be 6. The skiafy script already rounds > to > > the nearest hundredth. Maybe we should be rounding to the nearest 50th? 10th? > > From examining a random sample of icons on go/icons, two decimal places of > precision (where the last digit can be even or odd) looks to be the norm. Yes, that would be because the skiafy tool rounds to the nearest hundredth. Show quoted text > I > don't really see much advantage of changing the rounding logic, and doing so > will have the effect of changing the literals provided by these SVGs in ways > that could (potentially) cause incorrect rendering of the icon. Well if there were no rounding logic at all, we'd have random numbers like 5.9995838842. I took this to be an artifact of the authoring tool that Sebastien uses, and that this might as well be 6. I arbitrarily decided to round to the nearest hundredth. This 5.99 is making me wonder if that was the best decision. But, like I said, this is an "aside" and not something you need to worry about right now. tdanderson 2016/06/28 15:33:36 I was referring to the values inside the SVG sourc Show quoted text On 2016/06/27 22:41:14, Evan Stade wrote: > On 2016/06/27 17:23:59, tdanderson wrote: > > On 2016/06/27 15:10:36, Evan Stade wrote: > > > aside: I wonder if this really should be 6. The skiafy script already rounds > > to > > > the nearest hundredth. Maybe we should be rounding to the nearest 50th? > 10th? > > > > From examining a random sample of icons on go/icons, two decimal places of > > precision (where the last digit can be even or odd) looks to be the norm. > > Yes, that would be because the skiafy tool rounds to the nearest hundredth. I was referring to the values inside the SVG source of the icons pulled directly from go/icons before the skiafy tool has been used. Show quoted text > > > I > > don't really see much advantage of changing the rounding logic, and doing so > > will have the effect of changing the literals provided by these SVGs in ways > > that could (potentially) cause incorrect rendering of the icon. > > Well if there were no rounding logic at all, we'd have random numbers like > 5.9995838842. I took this to be an artifact of the authoring tool that Sebastien > uses, and that this might as well be 6. I arbitrarily decided to round to the > nearest hundredth. This 5.99 is making me wonder if that was the best decision. > But, like I said, this is an "aside" and not something you need to worry about > right now.
8 R_H_LINE_TO, 4.99f,

9 R_CUBIC_TO, 0.55f, 0, 1, 0.43f, 1, 0.96f,	8 R_CUBIC_TO, 0.55f, 0, 1, 0.43f, 1, 0.96f,

10 R_V_LINE_TO, 9.09f,	9 R_V_LINE_TO, 9.09f,

11 R_CUBIC_TO, 0, 0.53f, -0.45f, 0.96f, -1, 0.96f,	10 R_CUBIC_TO, 0, 0.53f, -0.45f, 0.96f, -1, 0.96f,

12 H_LINE_TO, 6,	11 H_LINE_TO, 5,

13 CUBIC_TO, 5.45f, 14, 5, 13.57f, 5, 13.04f,	12 CUBIC_TO, 4.45f, 14, 4, 13.57f, 4, 13.04f,

14 V_LINE_TO, 3.96f,	13 V_LINE_TO, 3.96f,

	14 CUBIC_TO, 4, 3.43f, 4.45f, 3, 5, 3,

15 CLOSE,	15 CLOSE,

16 MOVE_TO, 10, 2,	16 MOVE_TO, 10, 2,

17 R_V_LINE_TO, 1,	17 R_V_LINE_TO, 1,

18 H_LINE_TO, 7,	18 H_LINE_TO, 6,

19 V_LINE_TO, 2,	19 V_LINE_TO, 2,

20 R_H_LINE_TO, 3,	20 R_H_LINE_TO, 4,

21 CLOSE,	21 CLOSE,

22 END	22 END

OLD	NEW

« no previous file with comments | « no previous file | ui/gfx/vector_icons/system_tray_battery_alert.1x.icon » ('j') | no next file with comments »