View Issue Details
|Story Editor / Text Frames
|0004883: tab "zones" with margins and overflow control / warnings
|When using tabs to make tables, you probably don't want text overflowing from one field into the next or wrapping to the next line if it doesn't fit--that causes a mess. It would be good if each tab stop could have a field width or "zone" associated with it, with settings for whether and how text could flow out on either side: open (the default, allowing text to overlap other fields), clip to zone borders, bump to left/right (i.e. extend out the other side if you hit one border), etc., or even raise a warning (maybe at preflight time).... I'll post a mockup updated tab dialog in a few days.
A second use for this is allowing a tab stop to have different alignments (alternate stops at left, center, or right of the zone, if you like), including justified, within its zone. Then you could easily switch all the tab zones in a paragraph from left to right alignment at once, for instance, preserving the structure of the table as a whole.
|No tags attached.
|I'm inclined to close this as a "wont fix" since that's functionality you should use tables for. After all, tabs are only a poor-mans replacement for tables (and indents)
If the table functionality ends up being good enough, then we don't need to keep both concepts around at all. :) But at the moment at least, I think the semantics are a little different. Will you be able to import a text file, apply a "table style" to a paragraph with tabs in it, and get the expected result?
If everything would work the same (including workflow), then let's just eliminate tabs altogether, but I'm not sure it will....
I planned to implement tables as frames of its own, so you'd have to use an embedded table frame here. A function "convert selection to table" should be possible, using the tabs to put text into cells. Then you could apply a stle to the embedded table frame.
MrB insists of supporting tabs *inside* table cells, maybe you can help me talking him out of that! :-)
I guess I'll have to wait and see exactly how tables work. I'd want to be able to have the table rows use the local linespacing for their height, for instance, and import and export naturally as plain text, and things like that if they were to replace tabs. My general position is, I like having unified approaches, but I want to have flexibility in how I use a feature.
Would there be some way to make tabs--a kind of linear concept, with plain text input and paragraph styles--and tables, with a two-dimensional semantic, two interfaces to the same underlying system? So you could interact with and edit them from either perspective? I've thought about a general frame subdivision property; maybe a table could just be a paragraph-referenced subdivision entity, which is really no different from tabs, hence one concept and no question of tabs in cells or not.... :)
At any rate, what I don't like is a feature that exists but is limited in its functionality, which is why I filed these tab bugs; I'd say if we keep them they should have a logically complete feature set, or we're encouraging use habits that might not scale to more sophisticated needs. It seems to me tabs as they are, for anything besides indentation, are a recipe for mistakes and headaches, but the concept is useful.... :)
|Not in 1.3.4
|Note Added: 0014081
|Note Added: 0014082
|Note Added: 0014083
|Note Added: 0014084
|Note Added: 0014101
|Story Editor / Text Frames => Story Ed/Txt Frames
|Story Ed/Txt Frames => Story Editor / Text Frames