[Scribus] Character-by-character placement in PDF
Thu Oct 20 06:51:30 CEST 2005
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
- 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.
More information about the scribus