[Scribus] Character-by-character placement in PDF

[Craig Ringer]

Gregory Pittman wrote:
> Craig Ringer wrote:
> 
>> Gregory Pittman wrote:
>>
>>> Let me offer this observation. If there is a more or less absolute 
>>> need for efficiency of this type, consider that all of the pertinent 
>>> text information is really contained in the Scribus .sla file. This 
>>> file can be transmitted with a lot less overhead, especially if 
>>> you're just talking about text. There are only two requirements on 
>>> the receiving end -- a working copy of Scribus compatible with the 
>>> Scribus file type (1.2.x vs 1.3.x), and the correct fonts (though 
>>> subs can be done in a pinch).
>>
>> Honestly, I don't think that's realistic. PDF is a widely used and 
>> supported standard, and increasingly it's all that printers want to 
>> accept. The printers I deal with don't accept QuarkXPress or InDesign 
>> documents anymore (good on 'em); the chances of a printer taking 
>> Scribus docs are near zero.
>>
> I was trying to get a sense of where the question was coming from, and 
> not suggesting an alternative to PDF. I don't think Phil was suggesting 
> modifying the PDF format, or suggesting that printers would accept 
> anything else, and it's pretty clear why Scribus makes PDFs.

I'm a bit confused, to be honest. Your message certainly reads to me as 
if you're suggesting that they should just send the Scribus doc to the 
printer instead of using PDF. I find it difficult to see any other 
interpretation. That's not a bad thing, though I don't agree with the 
suggestion. However, if that wasn't your intent, I'm a bit confused as 
to what was.

> But, a small example of what I was referring to: I just converted a 23K 
> all-text single page .sla file into a 780K PDF. For transmission and 
> information purposes, the two files would be identical for someone who 
> has Scribus.

That's where we disagree, though I obviously did an insufficient job of 
explaining myself. I think that for transmission purposes they're very, 
very far from identical.

First, you need to consider images in that document size. You also need 
to consider fonts unless you're really, 100% totally certain the 
recipient has the exact same versions of all the same fonts you do. Even 
if they do, you generally want to include them anyway.

So, those two files are identical for the recipient's purposes except that:

    - For many purposes .sla requires an additional step to turn it into
      something the recipient can use (PDF).
    - The recipient won't have any professional preflight tools they can
      use to immediately check that the .sla fits their specs; they
      generally will for the PDF.
    - The .sla depends on fonts and images stored outside its self;
      the PDF is self contained. The user can't leave anything behind,
      there can't be problems with different image and font library
      versions causing special kinds of "fun", etc. The last thing I'd
      want to have to do would be start fiddling with Freetype when I
      just want to print a darn job...
    - The .sla needs a particular version of Scribus, where the PDF will
      work in basically any Acrobat / Acrobat Reader version (well,
      supported features permitting).
    - The PDF is closer to the final format. There's less chance of
      unexpected weird problems, and if there are the recipient doesn't
      have to worry about them beyond telling the sender that their
      document is broken.
    - Including all fonts and images, the .sla is probably going to be
      bigger (in this case - I know it's certainly often not).

In other words, if I was a potential document recipient who wished to 
print a document, I had the appropriate version of each piece of 
software requird, and you offered me the choice of PDF, Scribus doc, 
Quark doc, InDesign doc, or bitmap image for the document format, I'd 
take PDF every time. Even if it was massively larger. The only exception 
to that would be if I expected to need to significantly alter the 
document - and I don't know of any printers that want to do that if they 
can possibly avoid it.

I've been there. I've had to try to figure out how to print a Quark doc 
that uses "PC" TrueType and PostScript fonts, uses a plugin to inlude 
Windows Metafile images, and uses several plugins that aren't even 
available for the Mac quark version I was using at the time. I've also 
been on the other end, trying to figure out why the printers couldn't 
open the documents that my work had just producced. An hour before print 
deadline. With a deadline penalty rate of over AU$1000/hour. Scribus 
uses a similar "concept" for the format, in that:

    - It's not "forward compatible," ie 1.2.x can't open 1.3.x docs.
      I think that's the right choice, but it's still something that
      can cause problems if you try to use the Scribus format for doc
      submission.
    - It's not self contained, in that it relies on fonts and images
      stored outside the document its self. "Collect for output" helps,
      but experience with other apps suggests that this is never perfect.
      One machine will happily use fonts another chokes on and so on.

I see little reason to believe that sending .sla files (or packages of 
them and the images and fonts they depend on) would be any less painful 
than doing so with a Quark doc. I think that's fine - the industry is at 
a point now where we use DTP apps in-house, and PDF for external 
document exchange. Nobody needs to care if I use Scribus and you use 
Quark, or vice versa. Given this, I think that the use of the SLA format 
for document exchange is a very poor idea indeed, especially as a 
workaround for issues with larger than ideal PDF output.

> I do quite a bit with LaTeX, but for archiving purposes I 
> just keep the .tex file; it has everything I need for that purpose.

Absolutely. That makes perfect sense for archival.

I don't necessarily think it'd be reasonable to expect to be able to 
send your .tex file to a printer and have them deal with making it into 
a PDF though - they'd need all the fonts and images, any macro packages 
you're using, etc. ick. Archival is a very different thing to submission 
to a printer, and has different requirements. That's my point.

--
Craig Ringer