We Keep Coding

How do you all deal with the accessibility settings of font size and display size?

Whenever I test these accessibility settings with a larger display size or font size, it seems to almost always break parts of my layout and make it look awful. I really like the feature of autosizing text but these settings being changed seem to making autosizing text useless. Changing the display size also creates issues like weird holes in my table rows for reasons I can't figure out. Weighted views seem to break down in how they should work as well.
I have seen there are a couple of ways to work around these settings and making it so that the user's preferences of these settings do not affect your app. Do you all do this?
I understand the utility of the settings for the users. But, it seems kind of arbitrarily implemented because in order to make the layout work with these settings as a developer you might have to make your text size smaller from the beginning (in order to fit a larger font if user chooses to do this), which would lead to the exact same text size you, as a developer, would have chosen in the first place if you weren't trying to accommodate a larger font size being able to fit. I also believe I have heard that IOS doesn't allow for these accessibility settings to affect third party apps.
I am just curious how you all go about dealing with this. Thanks.

It is possible to ignore the user's preferred font sizing, by using dp instead of sp. Same for display size, if you really want to, you could check the current density and draw something according to that, still sizing things smaller. That's not a good approach. While your layouts will not break that way, the user who prefers a larger font/display sizes will still not be able to use your app, as they need a bigger text size.
There are some different techniques you can use to make layouts scale better:
Use minHeight/minWidth attributes in layouts, instead of hardcoding the sizes of the views.
Check that the constraints in constraint layouts are bound in both directions, not just start.
Allow text views to take up multiple lines, add ellipsis option where user can click through to see more information.
I wrote a blog post covering some of these in a bit more detail: Accessible Text Scaling for Android
Sometimes, however, fixing it for all scenarios will involve rethinking the design.
For iOS, the font settings also affect all third-party apps, it's not just an Android thing.

In general, you should always used scale-independent pixels, especially for a large body of text.
However if your text has to fit into a bounding-box of known size then you should use density independent pixels in order to ensure that the text always fits properly and that all characters are visible regardless of the users' setting.
Actually, Settings font size affects only sizes in sp. So all You need to do - define textSize in dp instead of sp, then settings won't change text size in Your app.
Here's a link to the documentation: Dimensions

GdxFreetype and camera: fonts become blurry

I generate my BitmapFonts at runtime with GdxFreetype. As the parameter.size is in pixels and I use a camera which scales up the scene, the font becomes blurry (even with texture filters at higher resolutions).
I need a way to create fonts based on the current resolution. How can I achieve that?

Just use two different cameras! One for your game that could have virtual size(say 16x20) and one pixel perfect camera. Draw those bitmap fonts using the second one. And for dynamically setting parameter size while generating them i personally use
ORIGINAL_SCREEN_HEIGHT/SOME_CONSTANT

Fonts and their sizes on different machines

I am writing a gui PC program with java and I am using Java Swing, the question is, for a given Font, with a given size and style, on a given String, i compute the bounding box (in pixels) on some machine, is there a possibility that on some other machine, for the exact same Font and exact same String, the computed bounding box will turn out different?
if it is possible( which seems to be the case according to the results I get on my program ), then how can i define a font where for a given string, in every possible machine, it will return the exact same bounding box?

You can't, because the rendering depends on several factors:
The font itself: some computers may not have the font you requested, or the font may have the same name, but be different in its substance. You can avoid this by embedding custom fonts in your deployable package.
The screen resolution: fonts are rendered accordingly to the screen resolution in DPI. On screens with higher density, fonts will be bigger (in pixel size), because they'd otherwise be unreadable. Think, for example, of Apple's retina displays, whose resolution is close to 400dpi, compared to a normal screen, with a 72dpi resolution. A string which is 72px high will take 1 inch on the normal screen, being perfectly readable, while will only occupy 0.18 in, being hardly readable.
The user has the right to customize the size of his fonts. If I'm presbyopic I'll want a bigger font size.
EDIT Or, you can fool the system by using pre-rendered strings (saved as raster graphics or even as SVG paths), but beware of the issues I presented you.

this is the intersection, setting :
Native OS,
accesible, instaled Font (Native OS uses different Fonts, size, bold ....)
theme in Native OS
Font (its properties) used for theme
various users setting, customs themes
idiotics custom application that can change global properties in Native OS, not applications setting
LookAndFeel
L&F uses own Font, are different
by default the same options as for Native OS
i**** custom application that can change global properties in Native OS.....
very different and too hard job is to change Font based on screen ration (in pixels),
any changes are about to iterating in UIManager and to change every key for FontUIResources

App widget inconsistent sizing between tablet and phone

I am attempting to design an app which reproduces the shortcut styles of the standard app shortcut home screen icons but as a widget. Note, this is currently just looking at the standard Android homescreen.
I have made the following observations using the "Dump View Hierarchy for UI Automator" tool in the DDMS -> Devices view of Eclipse:
The space given in the 1 x 1 square changes depending on screen density, orientation and whether the phone home screen is in "phone mode" or "tablet mode" (start a 4.x emulator and you can tell by the background amongst other things). Screen density effects the size as expected (0.75, 1, 1.5, 2.0 density factor scaling), but the orientation and 'home screen mode' are quite unpredictable. Specifically:
DIMENSIONS FOR A 1x1 'SQUARE' ON THE HOMESCREEN
Phone mode:
Portrait: 80dp x 100dp = 4:5 aspect ratio
Landscape (if available - not thoroughly tested): 106dp x 74dp = 53:37 aspect ratio
Tablet mode:
Portrait: 96dp x 96dp = 1:1 aspect ratio
Landscape: 96dp x 96dp = 1:1 aspect ratio
As you can see, there is barely any consistency whatsoever, but these are the dimensions given to a 'square' on the home screen. It gets even worse when looking at the space actually given to widgets (yes, it does differ from the square space available and used by the system shortcut widgets):
DIMENSIONS GIVE TO A WIDGET IN A 1x1 'SQUARE'
Phone mode:
Portrait: 80dp x 100dp = 4:5 aspect ratio
Landscape (if available - not thoroughly tested): 90dp x 58dp = 45:29 aspect ratio
Tablet mode:
Portrait: 72dp x 72dp = 1:1 aspect ratio
Landscape: 72dp x 72dp = 1:1 aspect ratio
So I'm stuck with:
Inconsistent aspect ratios between phone and tablet modes
Smaller areas given for an app widget then that of an app shortcut in some cases. Consequently, the relative and perceived size of widgets will look very different on a tablet vs phone?
The smaller areas aren't even vertically centred, they are mostly top aligned with a 2dp top margin which means they don't even look aligned with a neighbouring application shortcut to start with, let alone when trying to produce a similar looking shortcut through a widget
To visualise, the following images show a default system shortcut (with a red box surrounding showing the 'square dimensions - which both system shortcuts and widgets always share). Next to it is my widget with the blue highlight showing the bounds of a MATCH_PARENT setup, hence where the widget can actually draw within its 'square':
Phone - Port:
Tablet - Land:
Tablet - Port:
Most important to take from here, is the blue area of the widgets on a tablet does not even include the space where the system shortcut draws its text?
Does anyone have insights into:
Why the home screen is so inconsistent?
Why app widgets are not given the same drawing space as that of a system shortcut / or should it be and I am doing something wrong?
Should I be doing something else, or is it just accepted that for a 1x1 widget which takes up all its given drawing space, it will look 'smaller' (compared to its surroundings) on a tablet than it would on a phone?

And even better, many launchers allow the user to customize the size of their grid. Per the design guidelines for App Widgets, you cannot rely on an exact size on all devices. Instead, determine a minimum width and height and let the home screen determine how many squares the layout takes up.
They do provide some guidance on what you can expect for the minimum size of a cell (and all your numbers are much larger than that it seems), but again custom launchers may reduce this minimum even lower.
I find it best to focus on what components need to be in your layout (buttons, etc) and then follow the Metrics and Grids design guidelines to determine your minimal size (noting the margins are automatically added on Android 4.0+ devices but not on <4.0 devices). Then make sure your layouts are dynamic enough to fill in the space provided to them (centering text, etc as appropriate). Remember widgets are assumed to be a framed, single entry, rather than floating text as noted on the App Widget Design guidelines.

Hey you can manage the scree sizes in layouts you want to create different layouts for different screen sizes and also for landscape and portrait .
create the following layouts in your resource folder like this :
layout-large
layout-small
layout-xlarge
layout-landscape
And then copy your XML files in to it and check in preview screens for different devices you can have a idea based on that you can modify the size of the widgets in your homescreen.

Automatically scaling font to fit panel

I have an Swing app whose main panel is divided into a 3x2 grid of charts, and the app can be resized, with the charts (JFreeChart) auto scaling. One of these panels I would like to display the Apdex rating in, which is just text (e.g. '0.89 [0.5]*'). We use the application to display on a monitor visible to everyone, and scale multiple instances of the app that monitor different data centers. Scaling the Apdex font size to fit available panel space is what I'm after.
Any good ideas?

After re-reading and rethinking the question I would suggest for you to try calculating it yourself by use of FontMatrics stringWidth with the string and iteratively increasing the font size until you can, i.e. the size evaluated by you versus the available space.
A ready algorithm would be nice but I didn't hear of any.
Good luck, Boro.

I'd render it off-screen at some suitably large point size, as shown here, and then down-sample it using AffineTransformOp, as shown here.