[TIMOB-1618] Android: Expose Ti.UI.Label.minimumFontSize for Parity
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2017-01-27T23:46:09.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 6.1.0 |
Components | Android |
Labels | parity, tbs-1.8.2 |
Reporter | Ralf Pfeiffer |
Assignee | Hans Knöchel |
Created | 2011-04-15T02:57:29.000+0000 |
Updated | 2017-06-09T14:36:31.000+0000 |
Description
https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI.Label-object"> https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI... lists in properties:
minimumFontSize int
the minimum size of the font when the font is sized
based on the contents. Enables font scaling to fit
and forces the label content to be limited to a single line
This is extremely useful, however it appears to only be implemented on iOS; the property is never even checked in the Android code.
Attachments
File | Date | Size |
---|---|---|
Screen Shot 2016-12-30 at 21.04.59.png | 2016-12-30T20:06:35.000+0000 | 252675 |
Screen Shot 2016-12-30 at 21.05.38.png | 2016-12-30T20:06:34.000+0000 | 255767 |
Assigning tickets affecting StatusNet to our support contact per request.
We have worked around this for the moment using a hack scaling based on string length, but this obviously won't be very exact and could fail due to variable font metrics, etc.
Bug on StatusNet side: http://status.net/open-source/issues/2592">http://status.net/open-source/issues/2592
Agreed that it's not a super crucial issue, but I'm using minimumFontSize for at least 20 labels that can have variable text. I did the hack as well on the 2 or 3 most important ones, but it's definitely a huge time and effort (and bug) saver to have it.
Brian: does you hack take in a font size and label width and calculate the scaled font size from that? if so, would you mind sharing the code? I've developed one of my own but yours is probably much better.
My hack's been pretty manual, scaling the font size down based on the character length of the label beyond a hand-estimated 'maximum chars that should fit'. :) As with yours, I only did it on one or two high-priority labels.
A proper implementation should be using font metrics by asking the system how big that chunk of text would be rendered at a given font size, then keep bumping the size down until it fits in the available space. That could possibly be done by bumping around the size of a transparent or hidden label, but that's probably slower and nastier than having the Java-side code do it.
Sounds good. Mine's about the same (I estimate the text width based on a pixel length of an average character for that fontSize and fontWeight (bold or regular)...then scale from that...definitely a kludge. :)
This is another parity issue which is affecting an app I am building in 1.8.0.1 RC3
I would say if its not going to be scheduled for fixing that, the documentation state that its iOS only - I've tested this does not work on a label using 1.8.0.1 RC3 & using Google APIS 2.3.3
Note that this property is documented as iOS only in the 1.8 RC2 docs: http://developer.appcelerator.com/apidoc/mobile/1.8.0.1.RC2/Titanium.UI.Label-object Labeled as a parity bug so it comes up in the appropriate searches. Would be good to get this scheduled.
+1 for a fix to this
Community PR for this: https://github.com/appcelerator/titanium_mobile/pull/5909
Fixed the merge conflicts, updated the indentation and the docs. Updated PR: https://github.com/appcelerator/titanium_mobile/pull/8724 Demo:
Verified the fix with SDK 6.1.0.v20170131132207 Closing. Appc Studio : 4.8.1.201612050850 SDK Version : 6.1.0.v20170131132207 Mac OS Version : 10.12.2 Xcode Version : Xcode 8.2.1 Build version 8C1002 Appc CLI AND Appc NPM : {"NPM":"4.2.9-1","CLI":"6.1.0"} Ti CLI : 5.0.11 Alloy : 1.9.5 Node : v4.6.0 Nexus 6 running 6.0.1, Pixel 7.1.1