Hello Philip
Le 17/04/2020 à 21:08, Philip Race a écrit :
So if this is "always zero", for BufferedImage, why aren't we just
directly returning zero ?
For consistency with existing BufferedImage.getMinX() and getMinY()
method implementations. Those methods shall always return zero (this is
It is not a property of the Graphics (alone), itmust include any
transform on the font.
FontInfo, which is stored on the Graphics encapsulates all of that.
So effectively it is stored on the graphics but in the place that
accounts for the whole picture.
-phil.
On 4/17/20, 12:19 PM, Sergey
Just one question, did we check the possibility to save the "invalid" state in
the graphics itself?
So if the transform of the graphics, or transform of the text will be
non-invertible then we just return immediately
On 4/16/20 4:05 pm, Philip Race wrote:
On 4/12/20, 11:03 PM, Jayathirth D
Looks fine.
On 4/16/20 7:58 am, Philip Race wrote:
On 4/16/20, 6:31 AM, Sergey Bylokhov wrote:
Hi, Phil.
I have only the question about the new comment:
340 // Let's not adjust the metrics of any glyph that is zero advance.
341 if (slot->linearHoriAdvance == 0) {
342 return;
So if this is "always zero", for BufferedImage, why aren't we just
directly returning zero ?
I'm a bit on the fence about this wondering whether to submit a CSR here,
since a behavioural change is being introduced in order to conform to
the spec,
and there is some compatibility issue
Hello Jay
Le 17/04/2020 à 12:58, Jayathirth D v a écrit :
I have a question regarding test case. Why test has to check whether
we are getting negative value or not and then calculate whether the
tileGridOffset is 0. From different function's specification in
BufferedImage I see that there
Hi,
Change looks good to me.
I have a question regarding test case. Why test has to check whether we are
getting negative value or not and then calculate whether the tileGridOffset is
0. From different function's specification in BufferedImage I see that there
are no multiple tiles support.
I
