Cannot find First Line Offset

[brasscomposer]

I've been trying to wrangle with some text and align it across two columns. A friend recommended I use a First Line Offset setting. I'm on Scribus 1.5.3, and for the life of me, my Text Frame doesn't seem to have a First Line Offset tab/section/thing.

Where can I find it except for the F2-Properties when highlighting the Frame?

[a.l.e]

in the style manager?

in the properties palette when you highlight a selection?

why do you want it at a different place than the properties palette (F2)?

ciao
a.l.e

[JoergWausW]

I second the issue.

I declared styles to use for text boxes. After creating a text-box I choose my style and then I have to click a couple times to change that setting of First Line Offset. Every time. That's annoying.

I'd like to be able to set the First Line Offset as a paragraph style preset. It seems to be the only setting from the properties palette (F2) that is not available in the style dialogue anyway...

(It's missing in versions 1.4.6 and current 1.5.3, both portable)

[a.l.e]

ok, now i correctly understand the question... sorry.

there is a long standing request for it

https://bugs.scribus.net/view.php?id=9150

without a clear way to solve it.

i wonder if a short term solution would be to let the user pick a default in the preferences / document settings.
until somebody comes up with the description of a sane behavior.

currently, the best way to have a sane result is to use the baseline grid for all the styles that you wish to have correctly aligned.

[JoergWausW]

Thanks for the link. That is how I understood the problem....

I get the problem - it's a property for just the first paragraph in the textbox.

The problem occurs, because the distance between letters and the border of the text frame is too small.
If you have a visible border line around the frame, its middle is where the box contents ends. If this line is too thick, letters can collide with the line. Same happens in LaTeX boxes.

I guess a solution might be a style setting for all frames types like the padding option in HTML - define a distance between the frame border and its contents. Or does it exist and I haven't found it yet?

[GarryP]

As you have correctly deduced, the First Line Offset is only applicable to the first paragraph of text in a frame. Subsequent paragraphs have no need for such a setting since they flow from the text above. I believe this is the right way to do things, but see below.

First Line Offset should be set to either "Font Ascent" or "Line Spacing" by default as they are both more "natural" for users than the current "Maximum Ascent" setting. I have no idea why it's not. See this ticket from more than seven years ago: https://bugs.scribus.net/view.php?id=9150

You can add "padding" to a text frame via "Properties Palette / Text / Columns & Text Distances", however, as with the First Line Offset, it's only applicable to the text frame itself rather than the text within the frame so it can't/shouldn't be set as part of a text style.

Maybe it's time for Scribus to also have "Text Frame Styles"? First Line Offset, Columns and Text Distances, and Optical Margins could all be put into a style which could be applied to frames without altering the formatting of the text within. They would alter how the text is displayed but they don't need to interact with the text styles as they should work at a higher level before the text starts to be rendered. Just a thought.

[Nermander]

I'd say "frame styles" (both for image frames and text frames) would be more useful than the Line styles.

[GarryP]

I don't think that I totally agree with you Nermander. I could be persuaded otherwise but I'm not convinced. (I'm also doubting what I said myself earlier too.)

Usually I don't use Line Styles but - from what I remember - they have more functionality in 1.5.x so they could be just getting to the stage where they will actually be useful, if 1.6 is ever released.

A "Frame Style" that covers both image and text frames - and shapes, for that matter as image frames and text frames are just shapes that can have additional content - might be useful but you would have to confine the style to only those settings that are common between those things. Either that or have a Frame Style that included settings that might not be appropriate for all the objects that it's being applied to.

Outline and fill information could be covered, possibly including text flow settings and rounded corners, but there would have to be "sub-styles" also. One to cover the extra text settings and one to cover the extra image settings. Doing it this way you would have to have:
* Frame Styles - which would cover fill/outline/flow/etc;
* Text Frame Styles - which could have a parent style of a Frame Style but also cover text options;
* Image Frame Styles - which could also have a parent style of a Frame Style but also cover image options.

I think that's probably going a bit too far in complexity terms. Having styles within styles makes things more awkward for the average user. Personally I wouldn't have a problem with it but that's because I've been using Scribus for a while. I also don't know how much this sort of thing would be used. There's a lot of extra functionality that would have to be created that I really don't think most people would use. I understand that it might be very useful for people who have large complex layouts but I'm assuming that most Scribus users don't have large complex layouts. It's something that should probably be looked at for the future but I think it's going a bit too far as Scribus currently stands.

As a stop-gap solution, maybe a Copy/Paste Presentation function would be more appropriate. The user sets up a frame (or a shape) and then they can use Copy to temporarily make an in-memory copy of the frame (or shape) - as is already done - and then a Paste Presentation function could apply whatever formatting was appropriate to the object that was being pasted to.

For example, set up a text frame with two columns, a black border and rounded corners. Copy the frame, then Paste Presentation onto another object. If the object is a text frame then it would have all of the presentation formatting applied but if it was an image frame then the text formatting settings would be ignored (just the black border and rounded corners would be applied and not the two columns).

I think this would be a very useful function that would give most users some needed functionality without the need for lots of extra types of styles. Not a "fully professional" way to go about things but something that does the job relatively quickly without too much complexity.

[JoergWausW]

You can add "padding" to a text frame via "Properties Palette / Text / Columns & Text Distances", however, as with the First Line Offset, it's only applicable to the text frame itself rather than the text within the frame so it can't/shouldn't be set as part of a text style.

Yes, but this "padding"-solution also is not to be found in the styles dialog...

Maybe it's time for Scribus to also have "Text Frame Styles"? First Line Offset, Columns and Text Distances, and Optical Margins could all be put into a style which could be applied to frames without altering the formatting of the text within. They would alter how the text is displayed but they don't need to interact with the text styles as they should work at a higher level before the text starts to be rendered. Just a thought.

I'd rather think that a colums-option should be possible in the paragraph settings/styles. If you have a list of short items you might want to save room by making several colums - that also might be continued in the next text frame...

This is why I agree to have a general frame style (or parent and children styles... as you mentioned in the later post) - thinking of render frames as well that might also need "padding".

[GarryP]

You can't really apply padding to the text itself since the text could be in any frame. You could start the text in one frame where you need padding but it could flow into another frame where the padding was not wanted. If you applied the padding to the text as a whole then you wouldn't have the necessary control.

It's the same for columns. For example, there are plenty of occasions where you might want the text to be multi-columnar in one frame and a single column in another frame.

Consider the very crudely-made and boring example I've attached. The text flows from the top-left frame - which has left-padding to allow for the headline - into the "outside" middle frame - which is three-column - and then into the bottom-right frame - which has right-padding - and then into the "inside" middle frame - which has three columns and padding all round.

Setting the padding and/or column formatting to the text would make this very difficult indeed, especially when your paragraphs aren't wholly contained within a single frame.

Disconnecting the frame formatting and text formatting - as Scribus does - make things much easier in my opinion.

[attachment deleted by admin]

[Nermander]

* Frame Styles - which would cover fill/outline/flow/etc;
* Text Frame Styles - which could have a parent style of a Frame Style but also cover text options;
* Image Frame Styles - which could also have a parent style of a Frame Style but also cover image options.

For what frames would the first one be used?

[a.l.e]

let me suggest a few ideas:

- text options should not be defined in a frame style if they can be defined in a text (paragraph or character) style.
  (the current situation where frames can have text formatting is misleading and a source of bugs!)
- in the same way, we probably have image styles and not "image frame" styles.
- frame styles should contain formatting that apply to most / all types of frames.

this has been said, there might be reasons to indeed have specialized frame styles for each type... but i'd really like to avoid it if possible...

[JoergWausW]

@Garry P:
- I think the big columns in the middle third of the page should be three text frames.
- The boxed 3 coulmns in the middle would be what I consider either a table on top of the text frame or settings for a paragraph - if the content doesn't need to stick to a certain column.


@frame styles:
Sometimes I need several frames with the same settings, like border, color etc. - right now I just copy paste one and change what I want to change. But if I wanted to change for example the background color of all of them at once, I would need a frame style. This is where a "padding" feature would fit into (and that first line offset would be solved here as well.)
Maybe the easiest "workaround solution" would be to make sure that thick lines that mark the border of a frame don't interfere with the content...

And line thickness of the border could be chosen to overlap the contents or not.
(the workaround is to have two frames - one for the frame appearance and an unformatted smaller one on top for the contents. But if you want to move that, you have to move two objects. If you group it first, you cannot access the text content...)

I agree with a.l.e to keep it as simple as possible.
But:
As e.g. for image frames: I noticed that it's not possible to exchange a picture in an image frame without losing the formatting of the picture (like scaling and shifting), even if the new picture has the same pixel size. As long as this isn't staying the same, special image frame style features seem reasonable. But avoidable.

Back to "my private padding topic": this is reasonable to almost all frames (the shape-only ones would just ignore the setting)...

[GarryP]

I think I need to reiterate that I'm not a fan of introducing Frame styles, even though I brought the idea up. I think they would be an over-complication that wouldn't be necessary if we had a way of copying/pasting the presentation of frames (as I said above).

Anyway, Nermander, Frame Styles could be applied to Render Frames, or Shapes, or anything that contained the settings - line/fill/etc. - that were in the styles. Maybe a better name would be "Shape Styles", or something. A "Shape Style" could contain all of the settings that apply to all Scribus objects no matter what type of objects they are, e.g. line/fill/etc.

a.l.e, as I said above, not all text options can be applied to the text itself. To, again, reiterate, when a paragraph of text flows from one frame to another it's the frame that has to specify how the text is displayed, otherwise there could be all kinds of problems. For example, if the paragraph style says to use three-column then that text would have to be displayed three-column in every frame it flowed into. This would be wrong. I could give more example but hopefully this is enough.

Theoretically I don't think Image Styles would be a bad thing as being able to apply the same settings to multiple images might be useful but that could also be done using the "Paste Presentation" idea I gave earlier.

Being able to paste the "presentation" of objects shouldn't be a difficult thing to do. Scribus can already copy/paste whole objects so pasting the presentation of an object is just a subset of the paste operation. It simply doesn't apply the settings to the object if that object doesn't require them. For example, you copy a text frame that has a blue outline, a yellow fill and some padding. You then paste the presentation onto an image frame and the line and fill settings are applied but the padding is simply ignored because there's no text. It's a simple operation that would alleviate the need for the extra complication of having more styles. Add some way of tagging frames into the Advanced Select All and you can easily apply the same presentation to multiple frames at once.

JoergWausW, why use three frames when just one will do? In the example I gave the page has a 2(h)x3(v) layout. To add three frames horizontally would require more guides or some extra manual calculations. It's simply not necessary. And why use a table - which Scribus doesn't handle very well - when a three-column text frame does the job without any of the extra hassle? Doesn't sound right to me.

I agree that Scribus should have a setting which allows the user to say whether a thick outline of an enclosed area should be inside/outside/centred on the outline. That would be a useful feature.

The fact that Scribus loses any image settings when you replace the image in a frame has been brought up before. Personally I think it shouldn't do this and it's annoying to have to write down settings before replacing an image and then re-applying the settings. A very silly thing to have to do these days.

I'm not sure where padding would be used anywhere other than text frames (and maybe render frames, which are just "fancy" text frames). Can you supply an instance of where padding would be useful where it cannot already be mimicked otherwise?