View Issue Details

IDProjectCategoryView StatusLast Update
0016259ScribusScripterpublic2020-10-17 11:08
Reportershassan Assigned Tojghali  
Status closedResolutionno change required 
Product Version1.5.5 
Target VersionFixed in Version 
Summary0016259: BaseLine Grid Visibility on to get text to align to baseline
DescriptionI am using scripter to create character styles and paragraph styles, and also set the baseline. When creating paragraph styles to align with the baseline, this works most of the time, but there are a few text frames on the page in which the text does not align properly to baseline. I have to turn the baseline grid visibility on and then everything becomes aligned as expected. If I then switch off baseline grid visibility, the issue doe not return.
It is a pain to keep turning on the baseline grid visbility on manually each time to fix alignment. Please fix the bug and if possible introduce a function in scripter to turn on/off baseline grid visibility.

(Baseline settings that I am using: 1mm, offset = 0)

TagsNo tags attached.



2020-10-06 18:53

reporter   ~0048127

I forgot to note, if I turn on baseline grid visibility in document setup/preferences, and then create styles and text frames to align with the baseline, I still have the issue. I have to turn off the baseline grid visibility in document setup, and then everything aligns as expected.
No matter the case, it seems like the issue disappears as soon as baseline grid visibility is toggled on or off.


2020-10-07 06:40

manager   ~0048128

1 mm is not a sane value for a baseline grid

... except if you're writing "general terms and conditions"... which are also insane...

now, back to the serious things.

as far as i know, the text is not supposed to overflow the baseline height, but it can do so.
and there have been bugs in scribus for such cases.
your document is an extreme case and might be useful for tracking further bugs.

would it possible for you to provide everything needed for reproducing it?
the relevant part of the script?
eventually a base document?


2020-10-07 15:54

reporter   ~0048131

I agree that normally 1mm baseline grid is not a sane value for multi line text frames; however, my use case is a little different. I create several text frames next to each other (both besides and below) containing one line statements. Therefore, I need to set the baseline quite small to allow the text to snap to a baseline close to it without affecting its vertical position within the text frame too much i.e. to avoid the text falling out of view in the predefined text frame height.
I have written a simple script to reproduce the bug (please find attached). I have highlighted the alignment issue after the code runs in the attached png. As you can see, row 5 and 7 alignment are not correct like others. But once you toggle baseline grid visibility setting, it fixes it. Please investigate why this is happening and fix if possible. (1,460 bytes)
baseline_grid_bug.PNG (52,856 bytes)
baseline_grid_bug.PNG (52,856 bytes)


2020-10-08 07:07

manager   ~0048137

in your case you can simply use a fixed line height. and use it also for the first line in the frame (the default is

or, if you don't need the lines, just an indented text with a tab.

i will try to reproduce the bug you're facing, but i can't promise a solution... most of all if it only affects insane values for the baseline grid...


2020-10-08 07:29

updater   ~0048138

imho the baseline grid is working here. 'fife' and 'seven' are a bit lower as the other digits. (otherwise the wide top bars would look higher than the rest…)
this difference makes them jump to a higher baseline. the solution would be to set the 'first line offset' to 'font ascent' (instead of the default 'maximum ascent' – which is an insane default setting anyway…)


2020-10-08 21:19

administrator   ~0048149

Yes, the result for '5' and '7' is correct as these two numbers have a character height slightly below 3 x baseline while other numbers have a character height above 3x baseline. The bug here is to consider that baseline linespacing mode will align first line of different frames irrespective of their content. That's not correct as baseline linespacing mode act rather as an automatic linespacing mode than as a fixed linespacing mode. The solution for this kind of problem is to use fixed linespacing mode with first line offset set to "font ascent" as @utnik mentionned it in the previous note.


2020-10-09 00:51

reporter   ~0048150

I see what you all are saying about the height of the '5' and '7' characters that is causing it to behave differently. What I do not understand though is when I switch on/off baseline grid visibility in document setup, suddenly the '5' and '7' align on same baseline as example text next to it, which is basically what I wanted to see. Why is the 5 and 7 jumping down a baseline when the grid visibility setting is toggled?


2020-10-09 05:42

updater   ~0048151

the different heights are correct (with the actual setting) – and you know now how to change your settings to become sane ones.
i don't know why the numbers are jumping when you toggle the visibility of the baseline. but if this is reproducible (maybe even with a real baseline grid) it might be worth to file another bug report for this issue (or change this one, as the numbers are always positioned on the grid…)


2020-10-09 12:54

administrator   ~0048153

>> What I do not understand though is when I switch on/off baseline grid visibility in document setup, suddenly the '5' and '7' align on same baseline as example text next to it, which is basically what I wanted to see.

I cannot observe this here. The '5' and '7' stay on the same line they were initially on.


2020-10-09 15:21

reporter   ~0048155

Please see below video to see how the '5' and '7' are jumping back in line with text besides it when I toggle the baseline visibility setting:!Au1LeLYLAhkfgT7hedhzh2VsHVH_?e=1DIbtB

I have tested other baseline grid settings and the issue stops above 3mm (I suppose because this is more of a resonable value).


2020-10-09 17:52

administrator   ~0048157

Fyi there is an easier way to toggle, baseline visibility : View > Text Frames > Show Baseline Grid.

After investigation, when going through Document Setup dialog, the issue occurs because you are using a baseline spacing value which is not represented by an exact number of points. You should indeed note that baseline grid spacing is always defined in point units in document setup dialog whatever document unit is. Simply because font size is also defined in points.

Setting baseline spacing to 1mm will effectively set it to approximately 2.834645669 pt. Due to a Qt QDoubleSpinBox documented behavior (, this value will be rounded to 2.83 pt when going through document setup and there is no much way around. So to avoid any surprise, use a baseline grid spacing value which can be represented with a limited number of decimals in point unit, for example 2.83 pt or 3pt. In scripter, if current doc unit is millimeter, setting such value would look like:
setBaseLine(2.83 / 72.0 * 25.4, 0)


2020-10-09 18:23

reporter   ~0048158

Although I can do it manually, I cannot seem to find a scripter function to set First Line Offset to 'Font Ascent'. Does such a function exist? If not shall I create a new feature request for setFirstLineOffset and getFirstLineOffset?


2020-10-09 21:18

administrator   ~0048159

There is no such function in 1.5.5. i've just added getFirstLineOffset() and setFirstLineOffset() to 1.5.6.svn. So no need to create a new feature request!


2020-10-09 21:36

administrator   ~0048160

Here is a sample script which uses the new setFirstLineOffset(). Note that setStyle() has been deprecated in 1.5.6.svn and replaced by setParagraphStyle(). (1,632 bytes)


2020-10-10 00:13

reporter   ~0048161

Thanks a lot for doing that.


2020-10-10 23:34

reporter   ~0048162

Is there a way I can use setFirstLineOffset() now in v1.5.5? If not, do you have any idea when v1.5.6 will be released?


2020-10-12 00:58

administrator   ~0048163

>> Is there a way I can use setFirstLineOffset() now in v1.5.5?

No. Also 1.5.6 scripter will be based on Python 3, not on Python 2 like 1.5.5.

>> If not, do you have any idea when v1.5.6 will be released?

In a few weeks. Feature-wise we're done. A string freeze will be announced soon. Afterwards we'll have to wait around two weeks so that translators have time to update translations.

Issue History

Date Modified Username Field Change
2020-10-06 18:44 shassan New Issue
2020-10-06 18:53 shassan Note Added: 0048127
2020-10-07 06:40 ale Note Added: 0048128
2020-10-07 15:54 shassan File Added:
2020-10-07 15:54 shassan File Added: baseline_grid_bug.PNG
2020-10-07 15:54 shassan Note Added: 0048131
2020-10-08 07:07 ale Note Added: 0048137
2020-10-08 07:29 utnik Note Added: 0048138
2020-10-08 21:19 jghali Note Added: 0048149
2020-10-09 00:51 shassan Note Added: 0048150
2020-10-09 05:42 utnik Note Added: 0048151
2020-10-09 12:54 jghali Note Added: 0048153
2020-10-09 15:21 shassan Note Added: 0048155
2020-10-09 17:52 jghali Note Added: 0048157
2020-10-09 18:23 shassan Note Added: 0048158
2020-10-09 21:18 jghali Note Added: 0048159
2020-10-09 21:36 jghali File Added:
2020-10-09 21:36 jghali Note Added: 0048160
2020-10-10 00:13 shassan Note Added: 0048161
2020-10-10 23:34 shassan Note Added: 0048162
2020-10-12 00:58 jghali Note Added: 0048163
2020-10-17 11:08 jghali Assigned To => jghali
2020-10-17 11:08 jghali Status new => resolved
2020-10-17 11:08 jghali Resolution open => no change required
2020-10-17 11:08 jghali Status resolved => closed