Numbers and some punctuation display as superscript

Previous topic - Next topic


I'm brand new here, and just starting to learn Scribus, so please be gentle. I may have made an obvious rookie mistake.

My problem looks like this: When I enter certain glyphs, they are displayed as superscripts, smaller and higher than expected: October 3, 2020, is today's date. Testing (parentheses) and [brackets] I get something like this: October 3, 2020, is today's date. Testing (parentheses) and [brackets].

This happens when I copy/paste or write directly into both Story Editor and a text frame in the main display (called—?).

Superscripting happens to numerals and most punctuation, e.g. period and comma, but not colon nor semicolon. Parentheses and square brackets become superscripted, but not curly braces.

Is this a bug? An obscure setting I missed (or messed with, inadvertently)?

I spent a lot of time searching the forum and what other documentation I could find, not to mention delving into various menus, all to no avail. I considered either updating my bleeding edge version to 1.5.5 or switching to the stable version 1.4.8.*   So I am asking for help, and I hope this is the right place to do so. Thanks.

Oh ... is this the best forum for this issue?

I am using Windows 10, and this info comes from the About box:
Scribus Version 1.5.3
23 May 2017
Build ID: C--T-*-C1.14.6-Windows-64bit
* I installed this version a while back but never really used it. It Scribus seems perfect for my current (book-length) project, but only if I can get it to work. ;-)
Using Ghostscript version 9.50


hi misterart

i have never seen something like that.
could you provide an affected .sla file and the used font file?




As requested, attached are an .sla file and what I think is the Source Serif Pro font file I used. (This is the version that was in my \windows\fonts directory. There are also a couple of Source Serif Pro Regular files in a MikTeX installation, but they have .luc and .lua extensions.)

The forum software wouldn't accept the font file as is, so I changed the extension.

I fiddled around with a copy of my original document and got rid of the unwanted superscripts by switching to Ariel and back and/or changing the font size from 12.5 pt to 12.0 and then back again. But when I returned to the original font and font size, the unwanted superscripts were gone. So I don't know if that's helpful. I have used this same font in LibreOffice Writer without incident.

Anyway, I created a sample document, and I'm also attaching the PDF just in case that's helpful.

Thanks much,

[attachment deleted by admin]


... you seem to have activated the diagonal fractions in the font features...



Yes, that's it. I experimented with that feature earlier and apparently forgot to deactivate it.

However, I consider this to be, at the least, unexpected behavior. "Diagonal fractions" to me suggests that numerals on either side of a slash would be affected, but certainly not those in a date or other non-fractional use.

My inclination was to file a bug report, but it turns out someone already did ... in 2016 ( It was closed by Fahad because the code "works as expected." That's apparently based on the premise that selecting the diagonal fractions feature is intended for use in a style designed to be applied only to the actual fraction characters.

I disagree; as presented in the UI, there is no indication of this specialty use of a style. The ordinary reasonable person (e.g., me) would assume that the diagonal fraction feature would be activated only in cases where two numbers are separated by a slash.

Anyway, thanks for tracking down the source of my problem. I learned something, and that is good.



I think it is a know issue that there is no clear indication that specific font features are active?


hi MisterArt,

indeed, from that documentation page it seems sensible to only activate the feature when a "/" is there.

i wanted to suggest you to fill a new ticket with that information, but, first, i wanted to test it again.

since i had already removed the font you uploaded, i was looking for an installed font with the feature.

first I stumbled upon FreeSans: it lists the feature but nothing seems to happen when applying it.

then I found "Lato regular": and, oh wonder, it applies the feature exactly as you describe.
with "Lato regular", the feature is only applied when a "/" is between the numbers and you can safely apply it to the full frame.
(it's a free font so you should be able to find it and install it...)

so, scribus could implement it "more intelligently" but, on the other side, the font should do it already.
also, i don't think that scribus can check if the font does it in the right way, but it could replicate the work that the font should be doing. and do it all the time.

so you can pick: filling the ticket in the scribus bug tracker or on the font forgery side...



i just tested a couple of the fonts installed on my system. most of them show either all numerals (and other affected glyphs) superscripted as long as there is no slash between them, or they show no 'diagonal fraction' effect at all.
with some two or three fonts (lato medium, rubik...) the 'diagonal fractions' work in a sane way.
at least one font (freeSerif) applied the effect only to the two characters standing direct before and after the slash (1234/567890).
...'diagonal fractions' seems to be a bit difficult to implement.



The implementation of the diagonal fractions feature seems inconsistent, to say the least. Most interesting of the several fonts I tested was Libertinus Serif. A string of numbers 1234567890 produced nine small superscript glyphs plus a full-size zero at the end.

Another string I tested (PDF attached) was  123/456  12 3/4 56. The first fraction was rendered correctly, followed by a superscript 1 and a full-size 2, then the proper 3/4 diagonal fraction, a superscript 5 and a full-size 6. Normally, this sort of typography is restricted to avant-garde graphic design or quirky poetry.

I am inclined to post this as a bug, even if the fault may be with the font. Perhaps the best (interim?) solution is the addition of an alert triggered by selecting the diagonal fractions feature to the effect that the feature is implemented inconsistently in some fonts and that it may be safer to apply it only to the fraction. (F3 is your friend.) Most fonts will have glyphs for at least a few common fractions, e.g. ¾, ½, and in a pinch you can always write out "twenty-nine eighty-thirds."


[attachment deleted by admin]


as i wrote in my previous comment, i don't think that scribus can notice that the feature is not correctly implemented.

and i make my subtle hint a bit more clear: it's probably worth to fill the ticket with the fonts you want to use.
mentioning the fonts that implements it correctly to help them.

if you want to do so, you should probably first download the latest version, check it and if the fonts are actively managed, they might able to fix the bug.

in scribus, the advanced font features are a "new" feature and should still to be considered experimental (while i'm not aware of "technical" issues, the UI would really need a big improvement!)


i did some more tests with libreoffice and it seems to behave in a similar way as scribus.


i just took a closer look at two font files:

  • 'rubik' (one that generates neat diagonal fractions) has a complex scheme containing 35 different lookup tables and lookup subtables.
  • 'freeSerif' contains just two tables that search for glyphs (numerals, brackets...) followed by a slash and those following a slash. glyphs further away from the slash are not detected.
i'm not a font creator, but i can see some of the logical stuff you need to include for such a feature to work correctly – if someone needs the feature, he/she should tell the creator of the font (or the selling/distributing company) what works  and what doesn't...