Hey folks! Sorry for not getting back to this sooner, but my week's been pretty busy so far.
I've read and re-read many of the responses in this thread, particularly
a.i.e.'s, and it's pretty clear you folks have no clue what I'm saying.
Please quit myopically focusing on one single measurement
standard. This isn't about picas and points. And even deciding to just kill off support for that system will not address the issues I'm having, to say nothing of alienating a potential range of professional users.
I was producing a replacement label for a a Discgear 40 CD/DVD case:
http://i.ebayimg.com/00/s/MTE5OVgxNjAw/z/NEYAAOSw44BYN3Px/$_12.JPG?set_id=880000500FIn attempting to produce the label, I was running into problems doing offsets of repetitive objects, but also box border thickness, box sizes, etc.
When I would need to deal with a specific dimension (border thickness, box size, etc.) my ability to be precise enough to get what I was looking for depended on which measurement system I was using. So, for instance, I needed to offset the selector numbers a certain distance manually in separate text boxes since I needed 40 columns, which happens to be beyond the limits of numbers of columns supported by a text box. I can deal with that, but then when I wanted to offset the boxes so they'd line up, having at that point been in the MM measurement system mode, I couldn't get it precise enough. As it turns out, the offsets are 1/8", so simply switching into inches allowed me to enter it. Of course, I couldn't tell it 1/8 of an inch: I had to manually change that to the decimal value and then enter that.
Because I was building this from scratch and had to do measurements and some experimentation, it meant I couldn't have known in advance what exact dimensions, etc., for the label and all the objects on the label were supposed to be. In having therefore to mess around and experiment with different sizes and so forth, I found that I could not enter dimensions that were precise enough, oftentimes, in that particular measurement standard, so I'd have to change the document's measurement standard to something else where I could get the exact dimension I required. And simply trying to tell it some other standard in a different standard did not work. What would result is either a refusal to accept the measurement as entered (with, obviously, a conversion into the standard I was using), or it would give me some off-the-wall measurement in that particular standard which bore no connection to what I was trying to obtain.
Now, insofar as picas and points are concerned, here's the thing: PageMaker, QuarkXPress, and InDesign (to simply list the three major commercial DTP programs I've used extensively and therefore am competent to comment on) allow you to enter not just picas and points, but also fractional points. Traditionally, points are fractionalized into 10ths, so even though hypothetically one could have a 15th or a 17th of a point, I suppose, I've never in my life seen something like that used. And, in fact, Scribus will show you 10ths of a point. However, it won't actually let you enter that. You'd have to know precisely what that would work out to in one of the decimalized systems it supports, like inches or metric, create the object, and then when you'd switch the standard to picas, I suppose that decimalized fraction of a pica (to make up an example, 7p3.2) will actually show up.
If you don't believe me, try it.
If you randomly draw an object (say, a box) on the page, when you view it in picas, if it happens to be of a size like mentioned above in my made-up example, you will see it listed in the measurement fields of the Properties pallet in precisely the way I just described.
However, if you then attempt to tweak the dimensions manually by typing something else in, you will not be able to mess with the fraction at all.
By comparison, in the above-mentioned commercial DTP programs, you can enter whatever dimensions you like, irrespective of the current measurement standard selected, and it will accept those values without question, and it will then proceed to display the values in the measurement standard presently chosen. Moreover, in at least the case of QuarkXPress, you can (and I have) tell it you want a box with, for example, a horizontal dimension 3in + 7mm + 2p3.2 / 2 and it will, the moment you hit enter, give you whatever in the world that crazy length would be.
I don't think I can be more specific, descriptive, or explicit in what I mean than this. Any more than what I've said above would require me to show you in person what I'm talking about.
BTW, there are some other bits of behavior that Scribus has had right along, the basic design rationale of which I have never actually understood:
1. Let us say you have some text, and you've set it to a given font, size, weight, leading, etc. If you get rid of the text and replace it with something else, or if you hit return and want to continue on with a new line or new paragraph, none of that text has any of the above parameters set.
2. Leading settings make no sense. When you type in text, the default leading is the point size. Or, to put it another way, it's the default size with an initial additional amount of point space, and it does not change this leading setting when the font size changes.
3. The other options for leading (apart from setting it yourself) result in text which often doesn't have the appropriate amount of leading to it. This means you have to either know traditional leading values by heart (like 10 on 11, etc.) or you have to manually adjust them to something which looks decent.
4. When you apply other effects attributes to text (for example, outline or shadow) and then export the given layout as an SVG so you can place it as an image, or render into some other graphics format, those attributes are completely jacked up and make the resultant image unusable. It is first necessary to convert the text to outlines. Sometimes, it is also beneficial to convert Scribus-generated graphical objects, like arrow-headed lines, as bezier curves, and then export the image.
5. What does Scribus have against transparent backgrounds when generating a PNG?
I used to have a shop on CafePress. CafePress takes either JPG or PNG images, though they prefer (quite sensibly) to traffic in PNGs, since they look better and support transparency. So, when I would use Scribus to create a layout, I would have to go through the steps above in #4, then take the resultant SVG and use GIMP to render it at a given resolution, and then use it to export it as a PNG which I could then upload to CafePress.