Anyone else have all their docs text sizes fouled up in table layouts?
Every layout I have if I changed the default size in an area of the layout to TEXT it worked perfectly until a few weeks ago. Now, every area of any layout I use has the TEXT showing larger than the largest header! The “text” size was always the smallest size. Now, it’s huge and it’s thrown off every table I have!
In order to fix it I have to go into every table, every layout and change every field that was “text” as it’s size and move it to H3 I think is the option that is now smaller.
Am I the only one seeing this? It’s driving me nuts because I spent a lot of time making things look the way I wanted and now with one change by the Coda developers and everything is messed up and it will take days to fix!
Hey @Susan_M_Davis , I can also not reproduce this unfortunately.
Can you share one of the docs, to get a better understanding of it?
Can you remember the day since when this appears, so it maybe make it easier to connect the issue to a change that happend?
See this text and how large it is. Look at the settings. Text has never been larger than the headers yet now only in this situation where I’m using a layout is every field that I have set to TEXT showing larger than the headers. So every table I have is affected by this.
Since I’m using the Microsoft Edge browser, I opened my Chrome browser just to test it. The same thing is happening there as well. I wish I knew the exact date this started, I just don’t. I ignored it at first thinking it was just one table but it seems that this same thing has affected every table not just one.
Alright. Here’s a doc I just created and it behaves the same way.
If you look at the layout that first area which I would refer to as the title or heading area. In the past, you could put a column in that area and then click it and choose TEXT and it would resize to regular text. NOW, however, it seems to be ignoring the TEXT size in that area. Several formats have different areas and some of the areas the text shows in the text size and other areas the format default of that area is preventing the “text” to display properly. However, choosing any of the H settings does seem to change that size. SO it seems that just the text size setting is being ignored in specific layouts in specific areas. I’d call it a bug since it didn’t behave this way in the past and it isn’t consistent. If you cannot change the size of columns in the layout I would expect that to be consistent across all layouts and all areas. However, because only certain areas are affected and only the text choice then I’d say it’s aberrant behavior.
Dear @Susan_M_Davis , thanks for sharing. Now I was able to reproduce the issue. Or at least know why it behaves like that.
A quick style preformats fields in certain areas. The “Text” option is the “default” option, that automatically falls back to the format, that is defined in the quick area. So I’d say that is expected behaviour and not a bug.
Unfortunately, the quick styles can currently only be set per layout and not edited per field. The only solution is to move the fields out of that preformatted area and or to switch to the plain quickformat.
I personally don’t know if there was a recent change in that behaviour though. I’d have expected to be that way for a while already.
EXCEPT that…this is not the way it has behaved until recently. I’m calling it a bug because I’ve had these tables set up for months now and I’ve over-ridden those fields with the “text” before and it has “always” set the size of the text to text not to the larger sizes. There was a SUDDEN CHANGE that affected every table and the behavior is different depending on which area you place the column. Again, I changed nothing yet every table I have now has HUGE text where before it had standard text.
Now, if this is what was intentended, I’m fine with that and if I go and change every one of my tables so that it fixes this problem I can do that. HOWEVER, I want to know this is what was intended by the Coda develoeprs and not just some anomalous behavior that happened due to another recent change.
If you can choose the size of the text displayed in ANY of these areas of any of these layouts…and if it has always allowed you to choose your text size in the past, did Coda intentionally make a change that they wanted to default back to what that area was previous defined as when one selects text? Or is this a problem?
If it NEVER behaved in the past they way it did, that’s one thing. However, because every table I’ve created for a year now it was behaving DIFFERENTLY than it is now, the question that must be answered was…was it a bug in how it behaved before and I programmed using the bug and they fixed that bug. Or is it a bug now? One way or the other changing the inherint behavior of how something looks needs to be addressed.
Let’s say they decide to change H0 - H3 and instead of them going from large to small in the order they do currently, they REVERSED the order making the largest smallest and the smallest largest. That would need to be reported to the users that for whatever reason they have decided to change the look and that would throw every document created that uses those H sizes OFF! That’s what has been done with this. Were I creating a new document I’d just make it the size I want and not care that it works differently in one area of a layout than it does in the other. BUT…because it ALWAYS WORKED ONE WAY and now it DOES NOT? That throws everything I’ve created into chaos.
So…was it misbehaving before and they fixed it but I programmed with the mistake or was this change UNINTENTIONAL? That’s my question and no one seems to be able to answer it.
I’m guessing no one changes those sizes when they ues those layouts they just drag and drop things and if it’s large they leave it large. I don’t know that’s why I asked if others had the same issue I did.
It took me a little while to figure out what was going on and I think there are some situations when this works nicely, but I would have liked to make these layout changes myself rather than for this to have been applied automatically. The fix is indeed to reset the layout to standard and reorganize the fields again to your liking.
I agree with Daniel that this is not a bug but intended behavior.
