Customise cell Text Format

[arasaac-dga]

The idea is to add the following cell text customisation options next to the current "Convert element labels" option to "Element labels":

1. Position of the text in the cell (top or bottom).
2. Font Family
3. Font size (in factor mode as in accumulated phrase)
4. Font colour (with black and white as a main colours and a simple optional palette to choose)

[klues]

I've started working on this (as part of replacing the whole grid layout library with something better). Now I'm wondering about the details for the options of showing the text. See this screenshot, original at the top, my new experiments at the bottom:

For now I'm just using a fixed font size at the bottom. My questions are: what should be default behavious and what should be configurable with which options?

A suggestion for possible options:

• font-size:
  • automatic - automatic sizes text to fit in the available space
  • fixed - uses a fixed configurable font size and truncates it, if too long (e.g. with dots like Longer text be...)
• line-height: percentage of height that should be used for the text within a grid element (e.g. 20%). This applies only for text + image elements, in text-only elements all the space is used for text.
• maximum lines: default: 1, if set to 2, there could be 1-2 lines of text below the image (consuming 20-40% of the height with "line-height" of 20%). For only-text elements this would be ignored and the number of lines would be determined by the font-size and the size of the whole element.

@ms-mialingvo and @arasaac-dga please tell me what you think.

[ms-mialingvo]

Thank you!

• font-size: automatic as default.
  It would be good if these things were available as options, both for the whole set as well as for individual buttons. For example, for single-word-buttons - which are most of the buttons - I'd want to see a word like "expressions" fully but maybe I have a subpage with some buttons with long phrases for quick conversation, where the full text would take too much space so fixed font-size would be better there.
• line-height: The current ratio for iPad/tablets looks good to me as default.
• maximum lines: Sounds good.

font(-family) probably is whatever the browser's font is so it would be possible to change that there?

[arasaac-dga]

Great!!! Good addtion. Our comments:

• font-size: automatic as default. We agree. About adding the font-size option on each cell we consider that, at the moment, adding more options in cell edit makes it more complex. We consider that iniciatilly with the other options could be enough for most of the cases.

• line-height: ok, actual configuration is correct for us. Anyway, could be neccesary is some cases adjust the percentage. So, 20% as default, and possibility to adjust manually.

• maximum lines: for us, 2 must be the default option and offer only 1 as another option. Three lines we don't see.

• font-family: if it's possible to change font-family we consider that must offer a limited number of fonts prioricing "print fonts" like Roboto, Arial,... and fonts specially created for dyslexic for example (Open Dyslexic). But no more than 5-6 fonts. The most important for the fonts is that they are as legible as possible.

We add two more options one of them, the most requested:

• Text position: under or above the pictogram. This is the most requested option for our users.

• Font color: focusing in high contrast we would offer three options for color: black, white or yellow. No more options.

In case of long long texts if after all the settings are longer than cell space, the best would be to truncate and add ...

[ms-mialingvo]

I made an error in reasoning, I think. If the maximum lines is set to two, I guess the system recognizes if a second line is needed and only adds it if it's needed? For some reason I thought having two lines as default would mean it would add an empty second line if the word was too short, which is why I said 1 line as default. If the system adapts automatically, though, I too am for 2 lines as default.

If setting up font-family is a possibility, it would be important for me that one of the font is a font with the double-storey |a| and one is one with the single-storey |ɑ| (e.g. Futura) and that it still would automatically switch to the needed non-latin font (e.g. arab, devanagari) depending on the language of the board.

I didn't mention text position as it's listed in the first post but that sure would be an important option too.

[ms-mialingvo]

Font-family and text position would be enough to have as global option only, I think.

And then maybe font-size, line-height and maximum lines as both global option both as well as option on individual cells? I'm not quite sure if all 3 would be needed for individual cells. What do you think, arasaac-dga?

Would the line-height automatically fix issue #403, @klues ?

[arasaac-dga]

If the maximum lines is set to two, I guess the system recognizes if a second line is needed and only adds it if it's needed?

We also understand that although is set by default in two lines, the system automatically will use only one if two are not needed. The idea is set the max number of lines but not the lines that must be used.

If setting up font-family is a possibility, it would be important for me that one of the font is a font with the double-storey |a| and one is one with the single-storey |ɑ| (e.g. Futura) and that it still would automatically switch to the needed non-latin font (e.g. arab, devanagari) depending on the language of the board.

Yes we agree. It's neccesary to offer fonts that are suitable for some languages as you comment. Perhaps it would be interesting that the system sets, by default, a font-family for some content languages or that, the font-family list of fonts, list only the font that are suitable for those languages.

Font-family and text position would be enough to have as global option only, I think.

And then maybe font-size, line-height and maximum lines as both global option both as well as option on individual cells? I'm not quite sure if all 3 would be needed for individual cells. What do you think, arasaac-dga?

We are worried about introducing more complexity in communicator management. That's why we think that font-size, line-height and maximum lines must be only as global options. Introducing more configurations in cells makes everything more complex for managers that, in our experience, have low technical level.

[ms-mialingvo]

So, I just casually stumbled upon a board set that has the labels to the right of the image. I don't know what the reason is for that person to create it like that. However it reminded me of #57 and for that one, it would be helpful to have that option. Like for some users, it will be more helpful to have the different steps not from left to right (or right to left in Arab) but from top to bottom. And then it would be better if the text was on the right of the image (or left in Arab). The question is, should right/left position only be possible for such procedure plans or for all buttons, like is it easier to just programm it right from the start as option for all buttons? (Also, at that point the position should also become editable not just per set but per button)

We are worried about introducing more complexity in communicator management. That's why we think that font-size, line-height and maximum lines must be only as global options. Introducing more configurations in cells makes everything more complex for managers that, in our experience, have low technical level.

I think the way the editor is re-arranged and set up will have a big impact on that. Like for example in TD, most options are editable on set level, on page level and on button level. These are therefore a lot of options. However, because the settings are organised visually exactly the same for each level, it's really easy to understand and quite intuitive.

[klues]

Thanks for all your comments and thoughts! 👍

Instead of answering to everything separately I'll try to summarize all options and possibilities (also for me to have something to look at while implementing):

• text position: top (default) / bottom, maybe also left / right, if not too complicated to implement
• font-family: small set with good legibility, automatically adapts to content language, at least one alternative for double-storey |a| and single-storey |ɑ|
• font-size: automatic (default) or fixed to a specific value with truncated texts if too long (...)
• line-height: 20% as default, adaptable, maybe 60% default for elements with no symbols?!
• maximum lines: 2 as default, only uses 2 lines if text doesn't fit to one line
• font-color: at least black, white and yellow, but maybe simply freely definable like grid and element background colors (probably even easier to implement)
• color mode: color background or color border (not directly related to text, but I'm adding it here, so that I can implement it along with all of this, see Choice to color the whole button or just make a colored edge on the button #259 )

What should be default for text position and color mode? My feeling is that position top and color border are preferred for most people, but probably we shouldn't automatically change it for users with the update, should we?!

Would the line-height automatically fix issue #403, @klues ?

Currently I have some extra logic, which tries to increase the font-size of single character elements which is intended for keyboards. I would like to remove this extra logic and only use the new options. For this case 2 questions:

• what should be the default line-height for elements without symbols? I think this isn't so easy, because for single letters (keyboard) it should be big (e.g. 80%), but maybe there are elements with longer text, where it shouldn't be too big (e.g. 30%).
• probably the most coherent solution would be to add the possibility to set line-heigt / font-size also for grid-level and therefore being able to increase the font size only for keyboard grids.

For the question of how to arrange options and settings, I have opened a new issue to discuss this separately: #452

[arasaac-dga]

• font-color: at least black, white and yellow, but maybe simply freely definable like grid and element background colors (probably even easier to implement)

Yes, we consider that, for other colors, different to black, white and yellow must be defined at grid or cell level only. Globally has no sense.

What should be default for text position and color mode? My feeling is that position top and color border are preferred for most people, but probably we shouldn't automatically change it for users with the update, should we?!

For us, text position on bottom by default as is now and color mode with backgroud color as is now too. Most of the commercial communicators use background color by default and is most used option (although we understand the need of frame color as option).

Anyway, IMPORTANT, when you update Asterics with format text, the most important is that people don't see changes in their actual design. So, for example, if you decide, finally to set as default text on top, when you update don't chage this option for people. The same with others like line-height,font-size,.... It's important that the update is the most transparent as possible without generate "important" changes.

• probably the most coherent solution would be to add the possibility to set line-heigt / font-size also for grid-level and therefore being able to increase the font size only for keyboard grids.

Yes, although we are not in favour of introducing more settings in order not to introduce more complexity, we agree that some formatting (appearance) configuration of the grid specifically will be necessary by modifying, as you propose in the other issue #452 the current resizing window of the grid. It is important that boards like the keyboard ones, for example, look good and have their own specific configuration since they can be single-letter keyboards, multi-letter keyboards (in Spanish no more than 3) or keyboards where we use pictograms/images.

All the other options for format text/cell we agree with the proposal.

[arasaac-dga]

• text position: top (default) / bottom, maybe also left / right, if not too complicated to implement

We forgot to comment that we don't see the need of right/left text as global option for any case and in any case as global option.

[ms-mialingvo]

We are talking about font-size, but might image-size instead with automatic adaptation of font-size give more flexibility? "Let user define 0-100% of height of image/symbol, the font-size of the label adapts automatically to fit within the remaining space." #28 (0% image-size would then also equal to "hide all images", there was an issue open for that) Or does it end up being the same as it needs to add to 100% anyway?

We forgot to comment that we don't see the need of right/left text as global option for any case and in any case as global option.

As I don't know why pagesets with left/right text do exist, I'd have to ask actual AAC users first. It's a pity that there aren't more AAC users active in here.

For us, text position on bottom by default as is now and color mode with backgroud color as is now too.

Same.

[arasaac-dga]

We are talking about font-size, but might image-size instead with automatic adaptation of font-size give more flexibility? "Let user define 0-100% of height of image/symbol, the font-size of the label adapts automatically to fit within the remaining space." #28 (0% image-size would then also equal to "hide all images", there was an issue open for that) Or does it end up being the same as it needs to add to 100% anyway?

We consider more transparent for users config line-height as is planned (inside a global text configuration) and don't consider it useful to change the configuration to the image. We don't see the need to configure images globally and their size (don't see the need to set it to 0% to hide all the images). So, we prefer to continue with the actual way to configure Text-Images from Line-Height. It's more logical for us. 

[klues]

I also think that line-height makes more sense, since it's more clear what happens if there is more than one line (property maximum lines):

• line-height 20% and one line => image height 80%
• line-height 20% and two lines => image height 60%

But in the end it makes no difference regarding flexibility, you could still set line-height to 100% in order to hide images.

[arasaac-dga]

Totally agree @klues !!!

[ms-mialingvo]

But in the end it makes no difference regarding flexibility, you could still set line-height to 100% in order to hide images.

Alright.

I've been trying to figure out about the right/left labels and haven't been able to get any proper answer as to why this could be useful in some cases. So for me then, it also wouldn't be necessary to have right/left labels as global option, just for individual cells.

[ms-mialingvo]

Not directly related to this, but to have the same wording/style accross the settings:
In the collect element there is an option factor for font size of only-text elements in separated mode. Can that be changed to the same slider as for the other font settings? And I'm not sure what 'in separated mode' means, can't it simply be font size (text-only elements/mode) or so?

Edit:
So, after more testing, as the border(-color) settings are applied to the collect element too and it (like usually the other navigation elements that are usually in the global grid) doesn't necessarily need that, the collect element would also need the option for individual border settings. So - to again have the same structure across settings, for clarity - I'd put the border settings (color, thickness) together with the above-mentioned text setting in an 'apearance' tab, again with a overwrite default settings arrow-unfold thing.

[ms-mialingvo]

One last thing for the moment. I'd add some kind of informative sentence to background/border color in the element edit, so it's clearer to people that they can't decide there whether it applies to the background or the border but that that is set higher up, in the main settings.
Setting both, border and background color on element level will be a feature that I'll need too, but there is a separate issue for that (#259), I just specified that request there. (Issue #418 would then be an extended/upgraded version of that, that would make editing quicker.)

Besides the bug named by arasaac-dga, I haven't found other bugs across devices so far.

[klues]

So, when using multiple lines it only applies it properly ( = using multiple lines and keeping the set font size) after changing the mode for handling too long texts to something else than adapt automatically. It would make sense for it to work even if the setting is adapt automatically. And then, if the text is too much to fit even with two or three lines (as set) with the set font size, then it would get smaller than the set font size to fit into these lines.

Actually maximum lines: 2 along with adapt automatically also leads to 2 lines, at least sometimes. However, it's a difficult task to automatically adapt to the optimum font size with two lines (because you would have to determine how lines break with different word lengths). So if it's really important to have this working perfectly, please add a new issue, I won't be able to do it within this one.

All in all I think that the settings background color, border color, border thickness, font color and font size should be available on element level.

And Mode for handling too long texts and Maximum number of lines.

Really? What are the use-cases? Border / background color and font size is already possible to set on element level and for the other ones I think 99.99% of the users will not use them on element level, will they?

So, the size of the predict element text changes with the Font size (text-only elements) setting. However it isn't the same size as the key letters. With Auto-size keyboard letters deactivated, I would expect them to be the same size

It's because the predict elements are bigger and the font-size is related to the total size of the element (width and height). And it's not only taking the height into account because it makes the font size more stable on screen orientation change (rotation) on mobile devices.

Mode for handling too long texts and maximum number of lines don't seem to work properly for text-only elements? I've set the mode to elipsis and the number to 1 and stil get this:

yeah, maximum number of lines only applies to text + picture elements. I can also add a property for text-only elements, but I thought there it makes sense all the time to allow multiple lines.

[ms-mialingvo]

Actually maximum lines: 2 along with adapt automatically also leads to 2 lines, at least sometimes.

Okay, it's working in Firefox, it's Safari that's acting up ;) Or well, all browsers are acting up in general right now which makes it hard to test.

On mobile (Firefox, iPhone) it looks like this:
1 line, adapt automatically, font-size 12%. Actually, now that I'm seeing it on the big screen I see that it partly adapts, partly cuts off. Like the please be patient might get cut off because it might be already the smallest font size possible, but what's going on with can I have a turn?

2 lines, adapt automatically, font-size 12%. Doesn't look good.

2 lines, truncate/elipsis, font-size 12%. Looks good. Interestingly it also changes to this is if I move the mobile to vertical and then horizontal again while still in adapt automatically mode.

For clarification, are the >1 lines combinable with truncate and elipsis so that it truncates/elipses after 2 or 3 lines? I have the feeling that this was working but it's not working now so maybe I remember wrong.

Anyway, there is an issue with the browser on mac and windows as well as in firefox iPad after adding AG to the home screen, where it's not adapting the grid horizontally but making weird things (grid.beta only, public version works). Pretty sure it was working last week, I didn't notice any issue.
Screenshot of the entire screen from the ipad below, link for a video for the behavior in the browser (Firefox, but I also used Safari and then Edge on Windows with similar issues) here: https://we.tl/t-4Y3iB71bj6 . When going to fullscreen mode, part of the grid still stays cut off.

For settings on element level I'll answer once I can test properly again.

yeah, maximum number of lines only applies to text + picture elements. I can also add a property for text-only elements, but I thought there it makes sense all the time to allow multiple lines.

Okay, yes, it makes sense, but it needs to be made clear to the user. Any setting that is positioned as main, without additional remarks (like the (text-only elements)) I would expect to apply to all elements. So then it needs to be made very clear which settings apply to actually all elements, which apply to text-only and which apply to text-and-picture.

[ms-mialingvo]

It's because the predict elements are bigger and the font-size is related to the total size of the element (width and height). And it's not only taking the height into account because it makes the font size more stable on screen orientation change (rotation) on mobile devices.

So what are my options then to make the predict element font size the same as the keyboard letters and any surrounding buttons with text (like the just an element in the screenshot)?

[klues]

So what are my options then to make the predict element font size the same as the keyboard letters and any surrounding buttons with text (like the just an element in the screenshot)?

Currently the only way is to make the predict element the same size as the other elements.

I can also change the calculation of the font-size to only take the height of the element into account, this would cause the predict elements to have the same font size as the other text-only elements in your example (if auto keyboard letter sizing is disabled).

However, the reason that I take width and height into account is this - width and height left, only height right:

for small portrait-oriented screens it looks ugly if only taking the height into account, because the height is very big, which results in a quite big base font size, which then is adapted individually for each element.

Of course we could also add another option to let people choose between these modes, but I wouldn't do it, I think we already have enough options ;)
And we can also simply change it "take only height into account", if it's better for most big-screen users, ignoring that it looks ugly for small, portrait-oriented screens (which probably very little people use and they could still manually restrict the font size to a certain level to make it prettier).

What do you think should be the final solution? @arasaac-dga - what do you think?

[arasaac-dga]

Good morning. We are sorry but we have lost the "thread" on this issue. We cannot follow all the comments on this issue because we are very busy.

For our part, we do not see the need to include more options. As you know, we are in favor of simplicity and usability. In the case of predictive text, we see that it is enough for it to have the same font size as the text-only elements, taking into account that these elements only need one line unlike text-only cells that can have more than one.

We have many options and adding new ones will make their management much more complex for many of our users.

We do see the need to fix the text display issues we reported (which are cut off at the top or bottom depending on their position) in certain configurations (e.g. when the font size is reduced below 5%) or when the global board is used and it is integrated with the normal boards or, of course, when mobile screens are used (in portrait and landscape in some cases),....

If these issues persist, we see that perhaps the appearance of the text being synchronized between devices would not be the best because there is no uniform behavior between devices.

[klues]

If you resize under 5% font size is not usable, the text is hiden

I cannot reproduce this issue, I've tested it on Windows / Chrome + Firefox, Android / Chrome and iPad / Safari. For me all works fine. So maybe it's already fixed?!

because NaN% generate confusion and when you use move the selector the text is iniatialy very big.

it now shows (none) if it's not set. I need to have an "unset" value in order to be able to decide if the global values or the element level values should be used.

In Communicators like UTAC that use the Global Grid to place core vocabulary in left there is a lot of problems with category names and text size because what you see in preview view and in edit board in not the same that in view mode when the global grid is inserted.

I understand. I could try show the demo element in the same size it's shown in the actual grid (even after adding the global grid). But this would be a new issue. So please create a new issue for it and tell me if we should keep it as it is now or remove the demo element for now.

When you change the background color/border request you each time to validate it with the message.

Now changing the element-level background color automatically sets the color category to none, without this confusing message.

As discussed in #452, please put it in an appearance tab so it's the same as in the main settings

but I think this would need some more changes. Now nearly everything in tab General is related to Appearance, only the two boolean options in "advanced settings" are not. So maybe simply renaming "General" to "Appearance"? Or otherwise we could move all the things from tab "Image" to "General" and all appearance things to a new tab "Appearance".
What's your preference @ms-mialingvo and @arasaac-dga

I suggest Font size (mixed elements) or (elements with pictures) instead of just Font size

I've now renamed and re-arranged the settings like this:

I hope it's clearer that way.

In the collect element there is an option factor for font size of only-text elements in separated mode.

It's controlling this font size in the collect element if both text and images are collected (factor 3 vs. 1):

If you want to change something there - please a new issue ;)

I've now also changed/fixed these things:

• non-working auto-adaption of font size in Firefox should be fixed.
• bug with grid growing too big and being cut-off should be fixed.
• several improvements on performance, navigating between grids is again much faster (changes there introduced the bug above)
• Font-size is now calculated based on only the height of the element, not height and width, see previous comment
• fixed issues with maxLines set to 2, should work better now (although not perfect in all cases, ellipsis doesn't work with maxLinexs > 1 and it's still possible in some cases that auto font size is too big and not all of the text is visible) - as said if this is important to fix - please new issue.

[arasaac-dga]

I cannot reproduce this issue, I've tested it on Windows / Chrome + Firefox, Android / Chrome and iPad / Safari. For me all works fine. So maybe it's already fixed?!

The problem seems to be only on Microsoft Edge. In Chrome and Firefox reduce text size without hidde it.

it now shows (none) if it's not set. I need to have an "unset" value in order to be able to decide if the global values or the element level values should be used.

ok. Perfect

I understand. I could try show the demo element in the same size it's shown in the actual grid (even after adding the global grid). But this would be a new issue. So please create a new issue for it and tell me if we should keep it as it is now or remove the demo element for now.

Leave it as is now and if we see that suppose a real problem, we will add a new issue to take one of the decisions you propose. At the momment, forget it. We don't think that many people change font size with long-texts.

Now changing the element-level background color automatically sets the color category to none, without this confusing message.

Yes. Perfect. Perhaps it would be possible to remember the category selection before changing the background or border color, ideally if you reset the custom background color (by clicking Clear), the previous category would be selected again. But the system does not remember the previous selection, forget it.

but I think this would need some more changes. Now nearly everything in tab General is related to Appearance, only the two boolean options in "advanced settings" are not. So maybe simply renaming "General" to "Appearance"? Or otherwise we could move all the things from tab "Image" to "General" and all appearance things to a new tab "Appearance".
What's your preference @ms-mialingvo and @arasaac-dga

Our point of view is that if something has to be renamed, it should be the current drop-down menu, which is now called "Advanced options" and renamed to "Appearance options", removing the two options that are not appearance-related. The other two possibilities raised are not liked at all. The Image tab has enough importance and should not be modified. The general tab, in order to maintain coherence with the general configuration of the communicator, should continue to be called General, since it also includes "label" and the options to hide cell and to accumulate or not in the sentence, which are not appearance-related. Thus, we do not see in any case that the General tab should be renamed to Appearance because elements such as label are not appearance-related.

All other things ok.

[klues]

Thanks for your feedback! The two points where you said "forget it" I'll forget for the moment ;)

the Image tab has enough importance and should not be modified. The general tab, in order to maintain coherence with the general configuration of the communicator, should continue to be called General

For me it's also OK to leave it as-is. Another valid option for me would be to move all appearance-related stuff to a separate "Appearance" tab and the image to the "General" tab which then contains only the label and the image stuff (which are the most important things) in a single tab.
However, for the current release I would prefer to keep it as-is, because it's simply less work to do ;)

The problem seems to be only on Microsoft Edge. In Chrome and Firefox reduce text size without hidde it.

That's strange, for me also MS Edge on Windows 11 works without problems:

[ms-mialingvo]

Despite the tons of various comments/sub-issues you have managed to adress all, as far as I see :)

Font-size is now calculated based on only the height of the element, not height and width, see previous comment

Yes, I don't think that boards that are created for landscape will in general be used in portrait mode. People who want boards in portrait mode will create boards that fit specifically for portrait mode (so, less columns and more rows). I also don't think that it needs to be an additional setting option, so perfect now.

but I think this would need some more changes. Now nearly everything in tab General is related to Appearance, only the two boolean options in "advanced settings" are not. So maybe simply renaming "General" to "Appearance"? Or otherwise we could move all the things from tab "Image" to "General" and all appearance things to a new tab "Appearance".

Our point of view is that if something has to be renamed...

So, my main point is - and this is not specific to these font/border/color settings but in general - that the settings should have the same structure across all levels (settings for the whole grid, settings for single grid, settings for single element). If a setting is set under tab ABC for whole grid, it should also be under tab ABC for single grid (if it exists there) and under tab ABC for single element and the various forms of single elements (collect element, prediction element etc.) and in the future in editing multiple single elements. It's not logical to have it under tab ABC for the whole grid, then under tab DEF for single element and under tab GHI for collect element etc. Having the same structure on all levels makes the setup intutive, you get a logical expectation where you can find the setting, mixing it for each level makes it not user-friendly in my experience with various AAC apps. AsTeRiCS Grid has a lot of settings so anything that makes finding each setting more intuitive, without having to search in a manual or having to click through all settings until you find it, should be applied. The same-setting-structure-across-all-levels is something that is used in the setup of a certain other AAC app too and part of what makes that specific app one of the easiest for big-scale editing (next to the option to apply changes to multiple cells at once).
So, all in all it's not that important to me if the font, color and border settings are under an 'appearance' tab or within the 'general' tab as long as it's the same tab across all levels. Something that would speak against adding it to the 'general' tab is that it might get too overcrowded.

I've now renamed and re-arranged the settings like this:

Yes, now it's clear :) Small suggestion: Put mode for handling... and maximum number... directly beneath each other and font color either at top or fully at bottom of the advanced settings. mode for handling... and maximum number... are somewhat interconnected so they belong together in my view.

fixed issues with maxLines set to 2, should work better now

Looks good and it also erases my request for having mode for handling... and maximum number... on single element level for now.

ellipsis doesn't work with maxLinexs > 1

That's fine but I'd add some remark there like (i) except for the combination of ellipsis with several lines, all combinations are in general possible or so, so people don't think it's a bug when that combination isn't working.

And also yes to the rest (NaN etc.) :)

Except for #470 I haven't found any other technical issues across operating systems so far.

[klues]

@ms-mialingvo thanks for testing!

the settings should have the same structure across all levels

I agree with all of what you've said, but would still like to keep it as-is for now, since I want to come to an end for the upcoming release. But if at some point we add more element-level appearance settings, I can move all things to an appearance tab.

Small suggestion: Put mode for handling... and maximum number... directly beneath each other

Ok, I've done it 👍

so people don't think it's a bug when that combination isn't working.

actually it's a bug and I wouldn't explicitely describe it as non-bug 😄 I would wait until someone opens an issue for it, so then I see that it's actually something that needs to work.

[arasaac-dga]

That's strange, for me also MS Edge on Windows 11 works without problems:

In my case is Edge over W10 and after the last update the problem persists

So, my main point is - and this is not specific to these font/border/color settings but in general - that the settings should have the same structure across all levels (settings for the whole grid, settings for single grid, settings for single element). If a setting is set under tab ABC for whole grid, it should also be under tab ABC for single grid (if it exists there) and under tab ABC for single element and the various forms of single elements (collect element, prediction element etc.) and in the future in editing multiple single elements. It's not logical to have it under tab ABC for the whole grid, then under tab DEF for single element and under tab GHI for collect element etc. Having the same structure on all levels makes the setup intutive, you get a logical expectation where you can find the setting, mixing it for each level makes it not user-friendly in my experience with various AAC apps. AsTeRiCS Grid has a lot of settings so anything that makes finding each setting more intuitive, without having to search in a manual or having to click through all settings until you find it, should be applied. The same-setting-structure-across-all-levels is something that is used in the setup of a certain other AAC app too and part of what makes that specific app one of the easiest for big-scale editing (next to the option to apply changes to multiple cells at once).
So, all in all it's not that important to me if the font, color and border settings are under an 'appearance' tab or within the 'general' tab as long as it's the same tab across all levels. Something that would speak against adding it to the 'general' tab is that it might get too overcrowded.

If we want to maintain uniformity, the only option that we think we remember being discarded at the time is to add a new Appearance tab but without eliminating the General tab and, of course, the Image tab, which are important at the element level. In no case do we see that the Image tab should be touched or joined with others and the General tab allows us to accommodate the text label and the other additional options of hiding a cell or adding or not to the accumulated phrase (or future ones that may arise). In any case, in view of this launch and for convenience for Benjamin we continue to think that it is fine with the "Advanced options" accordion and at most renamed to "Appearance options". Afterwards, the unification with the board editing can be undertaken but that would only happen by adding a new appearance tab without touching the others.

[ms-mialingvo]

but that would only happen by adding a new appearance tab without touching the others

Yeah, that was what I was suggesting/intending originally.

[arasaac-dga]

Yeah, that was what I was suggesting/intending originally.

Anyway, we agree with Benjamin to delay it until there are more options and when grid edit or other pages like manage grid are redesigned. At the momment is ok in Advanced Options.

[klues]

In my case is Edge over W10 and after the last update the problem persists

strange. If it appears also for other uses, please open a new issue.

released with https://github.com/asterics/AsTeRICS-Grid/releases/tag/release-2025-01-27-08.34%2F%2B0100