Embedding Fonts

Previous topic - Next topic

IDN101

When I go to create a PDF and check the Fonts Tab....

I see the 2 fonts I have used (Arial Regular and Arial Bold) listed in the "Outline" box.

I select each one and click on the up arrow. This removes it from the Outline box but does "not" make it appear in the Embedded box? (which remain blank).

Should they not be then displayed in the Embedded box? (I'm running 1.4.6)

Many thanks,
Ian

GarryP

The embedding/outlining of fonts is something that Scribus gives you the impression of letting you control but what's in the UI doesn't always reflect what will actually happen. There's discussion about this in various other threads that go into various complicated topics that I won't repeat here. Long story short, don't assume that what Scribus says will happen will actually happen.

My best advice on this would be to export the document and see which text you can select. If you can select the text then Scribus has embedded the font, no matter what it said in the dialog. If you can't select the text then Scribus has outlined the glyphs.

It's not ideal, but at least you will know where you stand and can, perhaps, try different fonts/settings to see if you can get the result you want.

It's a bit of a lottery I'm afraid. Scribus knows exactly what it can and will do with the fonts, but it doesn't always tell the user.

a.l.e

i don't know.

i keep on having some random issues with a few fonts... but i'm really not sure if it's scribus or the pdf reader that is at fault...

also, if i'm not mistaking, the situation has gotten a bit better with 1.5 (less options, more sensible defaults).

a.l.e

back to ian's issue...

it's a weird issue.

are your fonts ttf or otf?

iirc, scribus 1.5 prefers the ttf ones...

GarryP

a.l.e, all I can add is that I've had situations where:
* a font in the "embedded fonts" box wasn't being embedded;
* a font says it can be embedded but Scribus doesn't embed it;
* a font is neither in the "embedded" or "outlined" box but it gets embedded anyway.
It's just how it is.

IDN101

Thanks guys.

Not had any actual problems with any of the final PDF's. Just seemed strange that the font names dissapeared from the interface once as soon as I tried moving them from "Outline" to "Embedded".

I will try selecting them in one of the PDF's.

a.l.e

garry, as i wrote above in 1.5 parts of the font handling has been improved.

if your issues still happen with 1.5 (and i think it's time for you to test it... but it's up to you!) i really think that the details are worth being reported in the bug tracker...

GarryP

Thanks, but I think I'll stick with 1.4.6, for the short-term at least. The main reason I use this forum these days is to help people with their problems and since - after another quick look at SourceForge - the vast majority of people use 1.4.6 (around 10 to 1 against using 1.5.x), that's the version I'll use.

1.4.6 may have its faults but at least I know what they are, for the most part, and how to cope with them. I can't say the same for 1.5.x. As they say, "Better the devil you know."

I don't really see the point in adding another Mantis ticket. Ian's issue seems to be closely related to this one https://bugs.scribus.net/view.php?id=11429 which was created in 2013. Quote: "When I select one of the outlined fonts and click on the up arrow button, the font disappears in the lower box, but doesn't appear in the upper box".

The attitude of the developer doesn't seem to be very helpful to me. User reports a problem; developer dismisses the user's concerns as "expected behaviour" - even though it was obviously not what the user expected - and closes the ticket within 20 minutes. No discussion, no trying to find out more information, no trying to get a user's perspective of the issue, just ignore it. If that sort of thing is happening, what's the point in users reporting problems?

utnik

hi garry
Quote from: GarryP on April 26, 2018, 09:53:50 AM...developer dismisses the user's concerns as "expected behaviour" - even though it was obviously not what the user expected - and closes the ticket within 20 minutes. No discussion, no trying to find out more information, no trying to get a user's perspective of the issue, just ignore it. If that sort of thing is happening, what's the point in users reporting problems?

jean's answer wasn't as bad as you describe it. he listed two different reasons for this 'expected behaviour', one of them is just to accept, the other is a standard setting, which can be changed...

utnik

GarryP

My point is that it is not expected behaviour from a user's perspective.
For a developer/expert who knows all about fonts and how they are - and can be - used, those reasons may be perfectly reasonable.
However, for the average user who just wants to put text into their document, they're not reasonable, or even fathomable.

Taking the developer's two points of reasoning:
* "some fonts cannot be embedded in PDF versions Scribus supports" - How does a user know this? Which versions? Which fonts? How can they tell?
* "fonts with more than 2048 glyphs (iirc) are subsetted/outlined by defaults" - How does the user know how many glyphs there are in each font? Is this something the average user would likely know? Do they have to count them? Is it subsetted or outlined? How would they know which one?

Essentially, the user is given two options for fonts, embedding them or outlining them. That's all they see so it's reasonable to assume that they are the only two options available (without going through the complex stuff in Preferences).
If a font is in neither box, how does the user know what is going to happen?
Or, to put it another way, where in the UI does it say what will happen to a font that is in neither box?

More information needs to be given to the user to tell them what's happening.
This is especially needed if someone is sending their documents to be expensively printed. Just hoping for the best isn't good enough.

a.l.e

personally, i also consider that if a font disappears, then it's a bug.

but, as said above, i'm not sure that this can happen with 1.5.

so, before telling that scribus has a bug, please check if this bug can still happen in the current code.

you don't have to use scribus 1.5 if you don't want and, indeed, for helping the users one should know how 1.4 works.

but if you want to make proposals for the future development or talk about bugs (most of all bugs that do not affect the most people in their daily business), i think you should first check the stand in the current development version.
there are bugs that will be fixed in 1.4, but generally speaking 1.5 is the future and that's where the development is done.

GarryP

Why should any normal user have to check to see if the problem still occurs in the latest developmental software?
Why should someone have to install two different versions of the software just to see if they can find one that works?

Imagine someone has a two-year-old car that they find a fault with. They take it to the garage and the technician says that it's a known inherent fault that's been fixed in the prototype of the next version. The manufacturer won't be retrofitting a fix to older cars but the customer can borrow the prototype if they want to. However, the manufacturer doesn't consider the prototype to be road-legal so it might crash because of some other unknown fault. Oh, and the manufacturer doesn't know when the next road-legal version of the car will be ready. None of that helps the customer who has to drive the car they already own.

If the user wants to use the current stable version of Scribus - because that's the version that the Scribus team itself considers to be the most stable version for production purposes - then anything that's been changed in the developmental code is irrelevant to that user.
If there's a bug in the stable version - which is the version that the majority of people are using - then there's a bug in the version that most people are using. In other words, most people have a version of the software that contains the bug.

If the software was being developed in a way where new stable versions came out fairly regularly, there wouldn't be so much of an issue. All the user would have to do was wait a few months and everything would be fine. If 1.5.0 was a stable version when it came out then that would have been fine. The same with 1.5.1, 1.5.2, 1.5.3, and 1.5.4 when that comes out. Having to wait more than two years for a fix to the version that most people are using puts those users in a very confusing and infuriating position. Do they use the stable version with its known issues, or use the developmental version with its unknown issues, or use some weird mixture of both?

If the problem being reported has been fixed in 1.5.x then that's great for people who are using that version, but it's irrelevant to the people who are using the version that is recommended for use by the team itself. Especially if there is no way for people to know when the next stable version might be available.

Personally I have no plans to move to 1.5.x. I can do what I want with 1.4.6 and if I have more complex needs then I have other software that I can use (either instead of, or in conjunction with, Scribus). Not everyone is in the same situation however. A lot of people can only use Scribus and they are being put in the position where they have to choose between using software that hasn't been updated since 2016 or software that has any number of unknown problems.

I really don't have much more energy to put into this discussion. The same issues keep coming round again and again, but they can be stopped once 1.6 is released. Once there is a new stable version - even if it does contain lots of bugs - everyone can be using the same version of the software and everyone can upgrade when the next set of bugs have been fixed. Surely that's a better way of doing things?

utnik

hey garry – take it easy!

we're talking about the possibility to make a mistake, which may end in a file with a missing font in the .pdf file.
if everything is done the right way, some fonts will be embedded as subsets – that's all.

utnik