You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Tom Chiverton <tc...@extravision.com> on 2015/12/07 14:33:32 UTC
Re: Mustella fixing (was Re: Next Flex SDK release)
On 24/11/15 19:00, OmPrakash Muppirala wrote:
> And do you think I can close this issue as fixed for now?
The Mustella tests are still failing...
Tom
RE: Mustella fixing (was Re: Next Flex SDK release)
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Well remember it's not just about rotating axis labels, but rotating the entire display to print out landscape easily.
We try to use only spark components where we can. But things like charts and PrintDataGrids help knock out some decent reports. However they are mx only.
For the embedded fonts, we have 4 declarations in our css. With / without CFF for both the regular font and bold font.
-Mark
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Tuesday, December 08, 2015 11:11 AM
To: dev@flex.apache.org
Subject: Re: Mustella fixing (was Re: Next Flex SDK release)
Ah yes, axis label rotation forces you to embed the fonts. I'm wondering
how many folks take advantage of rotated axis labels?
In your apps with Charts, are they using Spark controls in the rest of the
UI?
Many people have to embed both a normal and bold font, the thing is, with
the current code in the repo, if you had embedded those fonts with
embedAsCFF=true to use in Spark controls, you would have to now also embed
the font with embedAsCFF=false, and if you use bold labels on the Charts,
you would need to embed both the normal and bold font with
embedAsCFF=false.
-Alex
Re: Mustella fixing (was Re: Next Flex SDK release)
Posted by Alex Harui <ah...@adobe.com>.
On 12/8/15, 2:57 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
wrote:
>If I remember correctly one of the main reasons we started embedding
>fonts was to be able to rotate text on reports. The other being a
>consistent font no matter the platform/browser. We had to embed a normal
>font and a bold one. To make a smidge smaller, we used the
>"unicode-range" in the CSS.
>
Ah yes, axis label rotation forces you to embed the fonts. I'm wondering
how many folks take advantage of rotated axis labels?
In your apps with Charts, are they using Spark controls in the rest of the
UI?
Many people have to embed both a normal and bold font, the thing is, with
the current code in the repo, if you had embedded those fonts with
embedAsCFF=true to use in Spark controls, you would have to now also embed
the font with embedAsCFF=false, and if you use bold labels on the Charts,
you would need to embed both the normal and bold font with
embedAsCFF=false.
-Alex
RE: Mustella fixing (was Re: Next Flex SDK release)
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
If I remember correctly one of the main reasons we started embedding fonts was to be able to rotate text on reports. The other being a consistent font no matter the platform/browser. We had to embed a normal font and a bold one. To make a smidge smaller, we used the "unicode-range" in the CSS.
-Mark
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Monday, December 07, 2015 12:41 PM
To: dev@flex.apache.org
Subject: Re: Mustella fixing (was Re: Next Flex SDK release)
On 12/7/15, 9:07 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
wrote:
>
> To me it makes to have mx labels in the MX charts. If we create
>some spark charts, using spark labels would make sense. However you
>would have to embed the fonts again. The downside to not embedding the
>fonts and just using what your default font is, the tests would show
>bitmap compare issues more frequently. Right now it looks like the
>majority of the failures are bitmap comparisons.
Right, the failures are bitmap failures because there are slight
differences in the way TextField vs TextLine render text. I don't know if
that matters to anyone or not. If we decide not to support embedded fonts
for Spark Label, then someone can just cut new baselines and the bitmaps
will compare again.
More background: Back in the Adobe days, there wasn't enough time on the
schedule to create a whole new set of Spark Charts, plus I believe that
the thinking was that because Charts already provided a consistent
approach to customization of every aspect of the visuals, there wasn't
much to be gained by trying to create a whole new set of components on top
of SkinnableComponent. IOW, the actual chart component itself (PieChart,
BarChart, etc) doesn't have anything to be skinned, and it wasn't clear
that was much to be gained by having the things like the Axis and lines
and bars and wedges and other pieces be SkinnableComponents.
So, a bunch of code was added so that, if there is a Spark Label linked
into the SWF, the Charts would default to using that, otherwise in a pure
MX project, they use MX Label. I think that was done so you could use
Charts in Mobile projects which are supposed to be Spark-Only (and other
Spark-only desktop and web projects).
Maybe the better question is: Do any of you actually create Spark-only
apps? I don't know what the cost of embedding a font twice is for the
larger unicode fonts, but I thought that folks building out Mobile apps
were trying to make them Spark-only. But maybe you don't embed fonts in
Mobile apps or the additional size isn't a problem?
And as I mentioned earlier, I don't know if right-to-left text actually
would work in Charts with Spark Labels and whether there are other things
you can do with embedded CFF fonts that folks won't be able to use in
Charts that matter either.
So from a capabilities standpoint, I think we should support Spark Label
and embedded CFF fonts, but from a practical standpoint, I'm unclear
whether it is worth it.
-Alex
Re: Mustella fixing (was Re: Next Flex SDK release)
Posted by Alex Harui <ah...@adobe.com>.
On 12/7/15, 9:07 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
wrote:
>
> To me it makes to have mx labels in the MX charts. If we create
>some spark charts, using spark labels would make sense. However you
>would have to embed the fonts again. The downside to not embedding the
>fonts and just using what your default font is, the tests would show
>bitmap compare issues more frequently. Right now it looks like the
>majority of the failures are bitmap comparisons.
Right, the failures are bitmap failures because there are slight
differences in the way TextField vs TextLine render text. I don't know if
that matters to anyone or not. If we decide not to support embedded fonts
for Spark Label, then someone can just cut new baselines and the bitmaps
will compare again.
More background: Back in the Adobe days, there wasn't enough time on the
schedule to create a whole new set of Spark Charts, plus I believe that
the thinking was that because Charts already provided a consistent
approach to customization of every aspect of the visuals, there wasn't
much to be gained by trying to create a whole new set of components on top
of SkinnableComponent. IOW, the actual chart component itself (PieChart,
BarChart, etc) doesn't have anything to be skinned, and it wasn't clear
that was much to be gained by having the things like the Axis and lines
and bars and wedges and other pieces be SkinnableComponents.
So, a bunch of code was added so that, if there is a Spark Label linked
into the SWF, the Charts would default to using that, otherwise in a pure
MX project, they use MX Label. I think that was done so you could use
Charts in Mobile projects which are supposed to be Spark-Only (and other
Spark-only desktop and web projects).
Maybe the better question is: Do any of you actually create Spark-only
apps? I don't know what the cost of embedding a font twice is for the
larger unicode fonts, but I thought that folks building out Mobile apps
were trying to make them Spark-only. But maybe you don't embed fonts in
Mobile apps or the additional size isn't a problem?
And as I mentioned earlier, I don't know if right-to-left text actually
would work in Charts with Spark Labels and whether there are other things
you can do with embedded CFF fonts that folks won't be able to use in
Charts that matter either.
So from a capabilities standpoint, I think we should support Spark Label
and embedded CFF fonts, but from a practical standpoint, I'm unclear
whether it is worth it.
-Alex
>
>
>-Mark
>
>
>-----Original Message-----
>From: Alex Harui [mailto:aharui@adobe.com]
>Sent: Monday, December 07, 2015 11:24 AM
>To: dev@flex.apache.org
>Subject: Re: Mustella fixing (was Re: Next Flex SDK release)
>
>
>
>On 12/7/15, 5:33 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>
>>On 24/11/15 19:00, OmPrakash Muppirala wrote:
>>> And do you think I can close this issue as fixed for now?
>>
>>The Mustella tests are still failing...
>
>My understanding of the situation is:
>
>1) I'm still not sure we have the right solution in the repo. AIUI, there
>still isn't a way to use embedded fonts with Spark Label in Charts. You
>have to use device fonts, or embed both CFF and non-CFF and use MX Label.
>Nobody spoke up for or against having such a limitation so maybe it
>doesn't matter. If folks had spoken up that they wanted to use embedded
>fonts with Spark Label then I would volunteer to try to figure out how to
>get that to work.
>
>2) Mihai fixed a bunch of tests then ran out of time. Hopefully he'll be
>able to find more time soon. I don't know if were in a big hurry to get
>this release out, so I've been focusing on trying to finish up the FlexJS
>back port, which Peter and I hope to finish this week. Then I might be
>able to help out here if these are the only remaining issues.
>
>-Alex
>
RE: Mustella fixing (was Re: Next Flex SDK release)
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
To me it makes to have mx labels in the MX charts. If we create some spark charts, using spark labels would make sense. However you would have to embed the fonts again. The downside to not embedding the fonts and just using what your default font is, the tests would show bitmap compare issues more frequently. Right now it looks like the majority of the failures are bitmap comparisons.
-Mark
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Monday, December 07, 2015 11:24 AM
To: dev@flex.apache.org
Subject: Re: Mustella fixing (was Re: Next Flex SDK release)
On 12/7/15, 5:33 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>On 24/11/15 19:00, OmPrakash Muppirala wrote:
>> And do you think I can close this issue as fixed for now?
>
>The Mustella tests are still failing...
My understanding of the situation is:
1) I'm still not sure we have the right solution in the repo. AIUI, there
still isn't a way to use embedded fonts with Spark Label in Charts. You
have to use device fonts, or embed both CFF and non-CFF and use MX Label.
Nobody spoke up for or against having such a limitation so maybe it
doesn't matter. If folks had spoken up that they wanted to use embedded
fonts with Spark Label then I would volunteer to try to figure out how to
get that to work.
2) Mihai fixed a bunch of tests then ran out of time. Hopefully he'll be
able to find more time soon. I don't know if were in a big hurry to get
this release out, so I've been focusing on trying to finish up the FlexJS
back port, which Peter and I hope to finish this week. Then I might be
able to help out here if these are the only remaining issues.
-Alex
Re: Mustella fixing (was Re: Next Flex SDK release)
Posted by Alex Harui <ah...@adobe.com>.
On 12/7/15, 5:33 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>On 24/11/15 19:00, OmPrakash Muppirala wrote:
>> And do you think I can close this issue as fixed for now?
>
>The Mustella tests are still failing...
My understanding of the situation is:
1) I'm still not sure we have the right solution in the repo. AIUI, there
still isn't a way to use embedded fonts with Spark Label in Charts. You
have to use device fonts, or embed both CFF and non-CFF and use MX Label.
Nobody spoke up for or against having such a limitation so maybe it
doesn't matter. If folks had spoken up that they wanted to use embedded
fonts with Spark Label then I would volunteer to try to figure out how to
get that to work.
2) Mihai fixed a bunch of tests then ran out of time. Hopefully he'll be
able to find more time soon. I don't know if were in a big hurry to get
this release out, so I've been focusing on trying to finish up the FlexJS
back port, which Peter and I hope to finish this week. Then I might be
able to help out here if these are the only remaining issues.
-Alex