If you've ever wondered why people say tools like Scribus aren't ready for professional production work let me share this blog post by @davidrevoy
This should be a slam dunk. David knows what he's doing and One Bookshelf provides instructions that clearly show how to produce a PDF to their specifications.
We need to do better, folks. Color Profiles that work for everyone except FOSS tools are unacceptable. Period. There are no excuses for this.
If you want FOSS tools to still be the "I pay for it with my time because my time is meaningless" then we don't need to change a thing. Keep on making it so folks have to play some perverse roulette to ensure that things work with outside printers and publishers.
But if we're ever going to show that we're just as good as the professional tools then we need to start emulating all of the imperfections of those tools. Specs be damned, if everyone else figured it out so can we.
I've seen this with other independent creators where they use Scribus to print their book, only to get a mangled proof back that takes longer to sort out.
You know what they did to solve the problem? Did they file bugs and wait for patches? Nope. They bought InDesign because Scribus lost them over a month's worth of sales and they couldn't afford to keep puttering around with Scribus to make it work.
This is why professionals say FOSS tools like Scribus aren't ready for production work. Until it's fire and forget every recommendation of FOSS tools is just someone saying "please use this thing to satiate my religious convictions and pay for it with months of your time and missed income".
The nice ones tell you no.
@craigmaloney Fair points, though there are plenty of equivalent examples from the proprietary world.
What I appreciate about Linux / FOSS is that, _with a curated set of tools_, 1) things work and 2) they tend not to regress bugs (not perfectly, but usually).
The amount of sunk and lost effort I've put into proprietary solutions is ... large.
Leading proprietary tools don't follow, but set, standards. Bugs are spec.
That said: headline / keystone FOSS projects *should* get their shit right.
@brennen That's a definite factor.
Another option is for a particular entity which is on whole a *consumer* of a specific application to invest in its development. That carries all kinds of conflicts (free-riders, competitive advantage / disadvantage, etc).
In practice, a government entity _might_ find this to be worthwhile. Though those are subject to influence from commercial interests.
@craigmaloney So much this.
"Blame" is a concern where there's some sort of legal liability.
"Cause" is what you should look for in a technical issue (even where the technical issue is social).
Identifying _what_ goes wrong, finding the biggest source(s) of frustration, and addressing or mitigating those, then moving down the stack, gets results.
Identifying processes/procedures to avoid / address issues preemptively.
A current bugbear: improving projects' awareness / insight.
@craigmaloney There's *still* a huge issue with issue tracking, submission, resolution, and communication systems. And this is hardly specific to FOSS -- dealt with problems with Google, Reddit, Comcast, or your healthcare provider recently?
If anything, FOSS has improved tools (Bugzilla, GitHub/GitLab, etc.). They're still not good enough, and scaling is hard.
James Scott's "Seeing Like a State" has much relevance here.
Generalistic and moderated instance.