Measurements Entry issues...

Previous topic - Next topic

Portreve

Hello fellow Scribus folk and developers!

I have been actively using Scribus on a regular basis since roughly 1.2.1 or so, and right now I have both 1.4.6 and 1.5.3 installed. The issue has been constant for as long as I've been either tinkering with or using Scribus, and is still expressed in 1.5.3.

Here's the issue: When you want to manipulate measurements in the Properties pallet, your ability to be specific about measurements depends on which unit system you have active at that point. This is frustrating because in conventional DTP software (and here I'm thinking PageMaker, InDesign, and QuarkXPress) you can enter fractional units of equal values no matter which measurement standard you're using.

For example, let's say for technical reasons I need to make a box 3 picas, 3 and one-half points wide. If I type in 3p3.5, it will reject it and turn the box into a width of 0p8.02. If, on the other hand, I have measurement units set to inches, I can absolutely enter a decimalized inch value, at which point if I switch back to picas, the exact measurement I wanted will be displayed.

This sort of issue with measurement values appears to be global. That is, it's not just about X by Y sizes of graphical objects, but will also happen with weight (that is, thickness) of rules (where "rule" in this context means lines and box borders).

Also, and this is sort of tangentally related, when I have an object selected (say, for example, a line or a box) and I want to change the border thickness, the amount by which the border thickness changes depends on which measurement system I'm using. If I'm using points or picas, then the border will change in values of points. But, if I'm in inches, it goes from Hairline directly to 1 inch. And, once again, one has to play around with measurement settings in the document just to make changes to objects.

Because this behavior occurs with clean installations of any version of Scribus thus far used, and to the extent that Scribus is "normal non-coder end user modifiable" I have not in any way made changes to code, or scripts, etc., this clearly must be the software's default behavior, as opposed to something I've somehow unwittingly inflicted upon myself.

So, my question to the community and/or developers is: is there anything I can do to better handle this sort of behavior, or is this something to be addressed further down the development road?

BTW, I absolutely love the UI changes I've so far seen between 1.4.x and 1.5.x. Scribus' dev team has clearly been doing a lot of work, and I just wanted to say how much I appreciate their efforts.

I also have issues with text settings, but that's something for a different post probably.

Portreve

P.S.: This is my first post here.

P.P.S.: Note to Mods... please feel free to move this topic if I've posted it in the wrong area.

utnik

hi portreve

my standard setting is:

       
  • pt for text and the baseline grid
  • mm for all other ojects
but i can always enter numeric values like '3.4 in' or '40 pt' and scribus converts them into mm (or whatever is set as your standard unit...)

maybe i don't understand your problem...

utnik

Portreve

Quote from: utnik on September 23, 2017, 09:39:53 PM
hi portreve

my standard setting is:

       
  • pt for text and the baseline grid
  • mm for all other ojects
but i can always enter numeric values like '3.4 in' or '40 pt' and scribus converts them into mm (or whatever is set as your standard unit...)

maybe i don't understand your problem...

utnik

My problem is that you can't directly enter all possible measurements in any given measurement system. You have to keep changing the measurement system for the document into one of the ones which will correctly allow you to get the physical dimension (or other such measurement-related parameter) that you want. Sometimes, that's mm. Sometimes, it's points. Sometimes, it is decimalized inches. It's really aggravating.

utnik

hi portreve

this is not true! – or i still don't get the point...

i don't change anything in my document settings. i just enter '0.25 in' while the units are set to 'mm' and scribus interprets it correctly as '6.35 mm' (or a quarter of an inch...)

utnik

Portreve

I'm sorry, but I really don't know how else to explain it.

a.l.e

hi portreve

i think you should give exact examples of fields that behave in a way that is different to what expect.

you should tell us what is the default unit for the document (the one in the document settings, not in the preferences), what you type in the measurement box and what you get.

what i know about scribus:

- for most (if not all) you can explicit set the measurement unit and scribus will convert it to the default unit for that field.
- the default unit for the measurement fields is what you set in the document settings...
- except for fields that closely relate to fonts (like the font size) where the default is always pt.

you seem to use the "american picas"... which are not well tested in scribus, since most people tend use mm or inches...
personally, by using mm i never had any surprise when typing units in scribus...

Nermander

I cannot understand what "3p3.5" even means...

Do you mean 3 picas plus 3.5 points? I would write that as "3 p + 3.5 pt" (haven't tried if it works, but seems logical to me).

a.l.e

nermander, picas are a strange thing and -- afaik -- is only used in "traditional" (ehm ehm) american workflows.

thanks to louis' and peter's engagement (iirc), scribus does supports picas.
but almost nobody uses them.
so the support might have bugs.

if the bug is important we then have the choice to get it fixed or remove the support for picas (if the number of users relying on it is way too small vs. the effort to correctly implement it... and knowing how scribus works, i would bet that somebody will fix the code to get the picas to work).

but, for now, i still have no evidence that the picas have any problem, if they are entered the way they are supposed to.

the ball is on portreve's camp. please give us examples that show an issue in scribus.
which field does not "digest" picas correctly?
which does it correctly?
with which pica values?
with which document settings?

Portreve

#8
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=880000500F

In 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.

a.l.e

hi Portreve

as far as i understood your very long post, scribus should be able to do what you want, and if it does not it's a bug.

afaik, none of the people who know scribus enough on this forum is using picas, so we cannot judge if there is an issue or not.

we really need, that you tell us how we exactly we can reproduce the (potential) bug. something like:

- create a new document
- set the default unit to mm
- create a text frame
- set the width to 10mm in the properties palette
- set the width to 5p3.2
- you should see 8mm in the properties palette but you see 7mm

(of course, i made up the numbers and steps above: it's very likely that they are wrong!)

for the other questions... later : - )

Portreve

#10
Quote from: a.l.e on September 30, 2017, 06:14:07 PM
hi Portreve

as far as i understood your very long post, scribus should be able to do what you want, and if it does not it's a bug.

Hey a.l.e....

First off, thank you very much for being kind here, and working with me on this. No matter what else, I want you to know I do sincerely appreciate it.

So, let's walk through your suggestions. I'm using your starting points, and as you guessed, your eventual numbers were off, but that's ok. Let's take a look at what happens:


Create a new document and Set the default unit to mm:




Create a text frame and Set the width to 10 mm in the properties palette:




Set the width to 5p3.2




What you then get is 22.296 mm:




And when you change the default unit to picas:



So, it indeed is 5p3.2. Great.

------

Normally, a person using a given measurement system would not switch to another measurement system, either at all, or certainly to make the program give them the dimension they actually wanted. So, here's what happens if I don't use mm to create a 5p3.2 horizontal width text box:

Set the document as I would normally do to Picas as the measurement unit:




Create a text frame that, while you don't see it here, I successfuly typed in "10mm":




Next, I've typed in 5p3.2:




And, as you can see, it disregards it, reverting back to the existing value of 2p4.35:




Now, it may be of interest to note that when I typed in 22.296mm, which was the value given above for 5p3.2, it disregarded that entry as well. It's almost like Pica mode doesn't accept a decimal.

I'm not going to put more screen shots in at this point, but I just went through the whole process above yet again, but this time using Points as the default measurement.

Points accepts decimal numbers! It took both 22.296mm (and converted it correctly) and 5p3.2.

On a lark, I just went through all the measurement units and Picas is the only one which doesn't fully work. Every other one lets you enter decimals and converts it to whichever standard you're in. In fact, I just on a lark typed, while in Ciceros, "3in+1p", and I confirmed that I had a 19p wide box by switching to Picas. So, you can successfully do math formulas (at least up to a point), which has its uses.


However, there is one additional issue here that should be looked at... border thickness. That is, for lines as well as other types of shapes, like boxes, circles, etc.

When you're in Picas or in Points, you can change through clicking the thickness field arrows up and down through thicknesses, 1 pt at a time. However, when you're in Inches, it goes from Hairline to 1 inch to 2 inches to 3 inches... etc. It should be in points at all times. Now, if for some reason one wanted a 1 inch (or thicker) border, typing in "1 in" would be appropriate, but it shouldn't just treat the measurement unit as a quantity arbitrarily without regard to what you're talking about (points vs. inches).

Also, you cannot type in "Hairline". You have to manually click the arrow down in thickness until you get back to Hairline. Now, if memory serves me, I believe Hairline is like .25 points. Classically, you have Hairline, .5 point, 1 point, etc., etc.

utnik

hi portreve

i just decided to check about the pica issue – but i couldn't find any problem, as i only inserted pica values, and as you found out now, the problem only occurs when the standard unit of the document is set to picas. (looks like a bug...)

as soon as you set another unit for the document, you can insert your values in pica, mm, inches, ps points... and scribus does the conversion.
my standard is always 'mm'. but i frequently use inches and very seldom ps points. scribus never failed on the conversion.

Quote from: Portreve on September 30, 2017, 07:38:33 PM...you cannot type in "Hairline". You have to manually click the arrow down in thickness until you get back to Hairline.

just type '0' an you'll get your hairline – as a hairline doesn't represent a line width in a regular measuring system, you should always use real values when working on print files.

Quote...if memory serves me, I believe Hairline is like .25 points.

...something wrong with your memory here...
there's sort of a rule of thumb to generally distrust on anything below 0.5 points.
but a hairline ist the finest line you can represent by the actual technique and equipment – its width is not really defined in your file.

utnik

Portreve

Hi, utnik!

Quote from: utnik on September 30, 2017, 08:23:16 PM
hi portreve

i just decided to check about the pica issue – but i couldn't find any problem, as i only inserted pica values, and as you found out now, the problem only occurs when the standard unit of the document is set to picas. (looks like a bug...)

Yeah, well, I've kind of always suspected it was either a bug or just an oversight. Any possibility of getting it fixed? It's been like this in every version of Scribus I've ever used.

Quoteas soon as you set another unit for the document, you can insert your values in pica, mm, inches, ps points... and scribus does the conversion.
my standard is always 'mm'. but i frequently use inches and very seldom ps points. scribus never failed on the conversion.

Yeah, I already figured this out in literally going through every other measurement unit that Scribus supports, with the rest of them working perfectly and Picas not.

Oh, and btw, I love how I can type dimensions in using basic formulas, like "(3in+2p)/2" and it results in a 10p wide (or tall, or both) box.

Quotejust type '0' an you'll get your hairline – as a hairline doesn't represent a line width in a regular measuring system, you should always use real values when working on print files.

Hmm... Ok, but shouldn't 0 actually represent 0 thickness?  :P

Quote
Quote...if memory serves me, I believe Hairline is like .25 points.

...something wrong with your memory here...
there's sort of a rule of thumb to generally distrust on anything below 0.5 points.
but a hairline ist the finest line you can represent by the actual technique and equipment – its width is not really defined in your file.

Huh... I didn't know that. I know it does not print particularly well on my present cheap-o HP laser printer, though lines of that thickness will print (and have printed for me before) on commercial-grade laser printers, and of course on imagesetters.

utnik

hi portreve

Quote from: Portreve on September 30, 2017, 08:42:23 PMHmm... Ok, but shouldn't 0 actually represent 0 thickness?

either i need a line or i don't need it. in the first case it should be more than 0 (whatever unit) wide, in the second case i set the color to 'none' (independent of the line width...)

utnik


a.l.e

hi

thanks for the details!
now i see what the problem is!

and there seems indeed to be an issue there...

during the weekend i browsed through the bug tracker and here it is :

https://bugs.scribus.net/view.php?id=9933

i've linked your detailed walk through from the issue!

i seem to recall that thres has been a discussion in the past about picas, about stopping supporting dot values, because they don't make much sense.
but i haven't seen a pica in my whole life, so i'm not sure my memories are right...

all in all, it would be nice to have picas to work correctly in scribus, but i fear that we need somebody affected by the issue to fix it...
there are probably very few scribus users who need picas... and there are issues that are much more important.
but it might be something easy to fix by somebody who knows that part of code and  we might see miracles in the near feature... who knows?