Fixed
Status Update
Comments
ti...@google.com <ti...@google.com>
ib...@google.com <ib...@google.com> #2
The issue is reproducible with core-ktx 1.2.0 and 1.3.0-rc01.
ma...@gmail.com <ma...@gmail.com> #3
The Typeface.weight is not a weight of the underlying font file. It is a display style. On older APIs, the display style is adjusted if the Typeface is created from single font. However, after moving to CustomFallbackBuilder, that adjustment is removed since it can crate Typeface from multiple style font files.
Looks like it is good to set display style by ResourcesCompat.getFont for backward compatibility.
ib...@google.com <ib...@google.com> #4
Hi Nona,
Can you please schedule a release after you merge the fix?
ma...@gmail.com <ma...@gmail.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 3d6aa2e9b3243dcc4de1f54bd8d40339bd69cb05
Author: Seigo Nonaka <nona@google.com>
Date: Wed May 27 17:38:05 2020
Adjust the Typeface display style with the style of given font
This behavir is implicitly done by Typeface.Builder and
Typeface.createXXX function but not to be done by
Typeface.CustomFallbackBuilder since it is designed to be working
with multiple font files which has different style.
Looks like the style argument is ignored on older API implementation.
Bug: 156853883
Bug: 152023266
Test: ResourcesCompatTest#testGetFont_adjustDisplayStyle passes on 29
Test: ./gradlew core:core:connectedAndroidTest on API 29, 28, 23
Change-Id: I3a377c339a7aed50973cf11df86ddf0069f4ec25
A core/core/src/androidTest/assets/fonts/thin_italic.ttf
A core/core/src/androidTest/assets/fonts/thin_italic.ttx
M core/core/src/androidTest/java/androidx/core/content/res/ResourcesCompatTest.java
A core/core/src/androidTest/res/font/thin_italic.ttf
M core/core/src/main/java/androidx/core/graphics/TypefaceCompatApi29Impl.java
https://android-review.googlesource.com/1318947
Branch: androidx-master-dev
commit 3d6aa2e9b3243dcc4de1f54bd8d40339bd69cb05
Author: Seigo Nonaka <nona@google.com>
Date: Wed May 27 17:38:05 2020
Adjust the Typeface display style with the style of given font
This behavir is implicitly done by Typeface.Builder and
Typeface.createXXX function but not to be done by
Typeface.CustomFallbackBuilder since it is designed to be working
with multiple font files which has different style.
Looks like the style argument is ignored on older API implementation.
Bug: 156853883
Bug: 152023266
Test: ResourcesCompatTest#testGetFont_adjustDisplayStyle passes on 29
Test: ./gradlew core:core:connectedAndroidTest on API 29, 28, 23
Change-Id: I3a377c339a7aed50973cf11df86ddf0069f4ec25
A core/core/src/androidTest/assets/fonts/thin_italic.ttf
A core/core/src/androidTest/assets/fonts/thin_italic.ttx
M core/core/src/androidTest/java/androidx/core/content/res/ResourcesCompatTest.java
A core/core/src/androidTest/res/font/thin_italic.ttf
M core/core/src/main/java/androidx/core/graphics/TypefaceCompatApi29Impl.java
ib...@google.com <ib...@google.com> #7
Any way I can tell what version this will land in?
ib...@google.com <ib...@google.com>
ap...@google.com <ap...@google.com> #9
Great—works as expected, thanks!
ap...@google.com <ap...@google.com> #10
Project: platform/frameworks/support
Branch: androidx-main
commit 13cb54333c5e3202da0e2cdb566f0810fd217ae1
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:16:37 2024
Accept rationals (x/y) for attrs with legacy handling in ExifInterface
Some attributes declared/documented as type = Rational have special
handling for backwards compatibility that results in their values being
returned as decimals instead. Previous to this change, only decimal
values were accepted too, but we can accept both decimal and rational
forms without breaking backwards compatibility.
See more context about the backwards compat in this internal code review
comment from 2016:
http://ag/c/platform/frameworks/base/+/909922/2..9/api/current.txt#b20093
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ie282c1f8a23297f51a31b04c290284124eb870f9
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
https://android-review.googlesource.com/3037114
Branch: androidx-main
commit 13cb54333c5e3202da0e2cdb566f0810fd217ae1
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:16:37 2024
Accept rationals (x/y) for attrs with legacy handling in ExifInterface
Some attributes declared/documented as type = Rational have special
handling for backwards compatibility that results in their values being
returned as decimals instead. Previous to this change, only decimal
values were accepted too, but we can accept both decimal and rational
forms without breaking backwards compatibility.
See more context about the backwards compat in this internal code review
comment from 2016:
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ie282c1f8a23297f51a31b04c290284124eb870f9
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ap...@google.com <ap...@google.com> #11
Project: platform/frameworks/support
Branch: androidx-main
commit c23003716636d5c161e9b8c5d139ebbde0b7c8b5
Author: Ian Baker <ibaker@google.com>
Date: Wed Apr 10 17:03:20 2024
Split GPS_TIMESTAMP handling from the rest of the backwards compat rational tags
This tag has different special handling to the rest in this set, so it
doesn't really make sense to include it here.
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ibec7f06d8cfe2c7cd1edf029e32b002ce8e2e22b
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
https://android-review.googlesource.com/3039227
Branch: androidx-main
commit c23003716636d5c161e9b8c5d139ebbde0b7c8b5
Author: Ian Baker <ibaker@google.com>
Date: Wed Apr 10 17:03:20 2024
Split GPS_TIMESTAMP handling from the rest of the backwards compat rational tags
This tag has different special handling to the rest in this set, so it
doesn't really make sense to include it here.
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ibec7f06d8cfe2c7cd1edf029e32b002ce8e2e22b
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ap...@google.com <ap...@google.com> #12
Project: platform/frameworks/support
Branch: androidx-main
commit 34755e56581a1d2b474c2e556eab6b7c587aa116
Author: Ian Baker <ibaker@google.com>
Date: Wed Apr 03 14:10:27 2024
Improve precision of ExifInterface double -> rational conversion
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Iafd9736aab51fc627a7f25a11b9384b5008fb9bf
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
https://android-review.googlesource.com/3025043
Branch: androidx-main
commit 34755e56581a1d2b474c2e556eab6b7c587aa116
Author: Ian Baker <ibaker@google.com>
Date: Wed Apr 03 14:10:27 2024
Improve precision of ExifInterface double -> rational conversion
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Iafd9736aab51fc627a7f25a11b9384b5008fb9bf
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ap...@google.com <ap...@google.com> #13
Project: platform/frameworks/support
Branch: androidx-main
commit 67282b9c5804e5b8bb28993e57940b322b963988
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:30:03 2024
Document ExifInterface 'rational' attributes returned as decimals
These specific attributes have special handling, for backwards
compatibility with the implementation of ExifInterface that preceded the
platform android.media.ExifInterface. See more context in this
internal code review comment from 2016:
http://ag/c/platform/frameworks/base/+/909922/2..9/api/current.txt#b20093
Also add tests for this handling, including the current behaviour of
rejecting/ignoring the 'correct' rational format when passed to
setAttribute(String, String). A follow-up change adds support for this
format (and updates these tests to reflect this).
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ia09c2956f0f80279108ccf872174eb98214a38a8
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
https://android-review.googlesource.com/3037113
Branch: androidx-main
commit 67282b9c5804e5b8bb28993e57940b322b963988
Author: Ian Baker <ibaker@google.com>
Date: Tue Apr 09 17:30:03 2024
Document ExifInterface 'rational' attributes returned as decimals
These specific attributes have special handling, for backwards
compatibility with the implementation of ExifInterface that preceded the
platform android.media.ExifInterface. See more context in this
internal code review comment from 2016:
Also add tests for this handling, including the current behaviour of
rejecting/ignoring the 'correct' rational format when passed to
setAttribute(String, String). A follow-up change adds support for this
format (and updates these tests to reflect this).
Bug: 312680558
Test: ExifInterfaceTest
Change-Id: Ia09c2956f0f80279108ccf872174eb98214a38a8
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java
ib...@google.com <ib...@google.com>
na...@google.com <na...@google.com> #14
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-alpha01
Description
Version used: 1.3.6
Devices/Android versions reproduced on: ALL
Steps to reproduce:
1. Create ExifInterface for an image file
2. Set time exposure attribute to value 0.000625 which corresponds to time exposure value of 1/1600
3. Save attributes to image file
Actual outcome:
- When reading exposure time value from that file the value is 0.0006, so it is truncated. This results in exposure time changed from 1/1600 to 1/1666.
Expected outcome:
- The exposure time value should be 0.000625 which corresponds to the expected exposure time value of 1/1600.
Reproducibility:
It seems to occur on all devices and all image files/formats. Likely the problem is that the double value is converted to rational value which has limited precision.