Avery 8167 label printing

classic Classic list List threaded Threaded
31 messages Options
12 « Prev
Gary Dale Gary Dale
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

On 10/02/16 10:53 PM, Ken Springer wrote:

> On 2/10/16 4:27 PM, Gary Dale wrote:
>> On 10/02/16 12:01 PM, Ken Springer wrote:
>>> On 2/10/16 8:28 AM, Gary Dale wrote:
>>>> On 09/02/16 11:39 PM, Ken Springer wrote:
>>>>> On 2/9/16 2:23 PM, Gary Dale wrote:
>>>>>> On 09/02/16 03:23 PM, Dave Liesse wrote:
>>>>>>>
>
> <snip>
>
>> PDF is a great way to exchange documents but it has an interesting print
>> option (usually) of shrinking to fit the printer margins. If you send a
>> PDF label set, you need to remind the recipient to print them full size.
>> I've run into this problem several times where my carefully crafted PDFs
>> aren't printed the way I designed them.
>
> In this case, IMO, the creator of the PDF should be aware of the
> potential margin issue and set them accordingly.  So far, I've never
> been burned that I know of by using .5" margins except with the top
> margin of the 8167 labels.
>
> So there should be no need for shrink to fit unless we are talking a
> totally different page size.
>
> But it's awful hard to break people's mindset and get them to switch
> to PDF.  "Oh, if we are going to share and work with the same thing,
> we both have to have MS Word."  Or WordPerfect.  Or Lotus' word
> processor in the old days, I can't remember the name. At one time,
> this was absolutely true.  But it's no longer a mandatory thing with
> PDF on the scene.
>
> There will be situations where where Word, or Excel, or ???????? will
> be required.  But it's because that software is already in use across
> the enterprise.  It's not because it's the only software that will do
> the job.

That's not the issue. Sometimes you want something to occupy the full
page for professional printing but people use their home printers instead.

As for using the same software, that doesn't solve problems if the
person doesn't have the same fonts installed that you do. The PDF format
removes the requirement to stick to common fonts.

Similarly the ISO standard Open Document formats that LibreOffice uses
allow documents to used by other programs, including the M$ ones. They
may not look the same, but will at least be exchangeable and editable.

>
>>
>>>
>>>>>
>>>>>> There used to be a problem with multi-column labels but they seem to
>>>>>> have redone the label specification to correct that. When creating
>>>>>> labels, there is "Format" tab that lets you adjust the label
>>>>>> properties.
>>>>>> In its new incarnation, it is easy to use and gives you exactly
>>>>>> what you
>>>>>> need to adjust the properties of incorrectly specified common label
>>>>>> formats down to 1/100 of an inch.
>>>>>
>>>>> In the end, I'll probably do this.
>>>>>
>>>>>> You can specify the top margin, label height and vertical pitch (the
>>>>>> last two may be different if there is space between the labels)
>>>>>> and do
>>>>>> the same for the left margin, label width and horizontal pitch. They
>>>>>> also allow you to specify the page size and the number of rows and
>>>>>> columns.
>>>>>>
>>>>>> If you think a label isn't defined correctly, fix it. Also, file
>>>>>> a bug
>>>>>> report so that the developers can fix it for everyone. It's
>>>>>> better to
>>>>>> light a candle or two than to curse the darkness.
>>>>>
>>>>> In this case, the label spec is correct.  Font design will have to
>>>>> have a factor in this someway too, I suspect.
>>>>
>>>> It shouldn't unless LO calculates the position of the next label
>>>> relative to the end of the previous text. It would seem more natural
>>>> (and simpler) to calculate in absolute terms.
>>>
>>> Upon retrospect, I agree.  But it is something you have to be
>>> cognizant of when designing the label, as it can affect the apparent
>>> vertical centering of text on the label.  Which can effect what you
>>> think may be happening with label output.  In my case, the label
>>> includes a graphic, which is unaffected by text positioning. Makes it
>>> easy to figure out where the problem is likely to be.
>>>
>>> Another overall negative effect of this problem is, you have to ask
>>> yourself, if this is broken, what else in the suite is broken?
>>> Especially if you are using LO to make a living.  Is there another
>>> feature I use in Writer that doesn't work correctly?  What if one or
>>> two functions in the spreadsheet calculate incorrectly?  What if Base
>>> occasionally mangles your data?
>>>
>>> I remember years ago when Intel turned out a chip that had an error in
>>> it's math calculations.  It was a rare happening, but when they
>>> finally admitted it publicly, trying to say it wasn't important do to
>>> the rare occurrence, it did not go over well at all! <G>
>>>
>>
>> I've yet to find software that is perfect (except of course for what I
>> develop  ;)  ).  Big suites like LO will have the occasional bug but
>> I've never found one that was more than an annoyance.
>
> It's an annoyance if you can find a workaround.  It's a problem if
> there's no workaround, and it's something you need to get your job done.
>
> And, if it was something I produced, I won't be happy until it's
> fixed.  "Close enough" just doesn't work for me in a lot of cases.

You did find a workaround though. As for perfection, the universe
wouldn't exist if there was such a thing.

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
steveedmonds steveedmonds
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

In reply to this post by Cuyahoga Falls
And there is the distinction between precision and accuracy. You can be
very precisely inaccurate.
Steve

On 2016-02-11 12:14, Virgil Arrington wrote:

> Thanks for the explanation. Oddly enough, it makes some sense, even to
> my non-techy brain. What I found interesting was that, in the
> spreadsheet, I got the "wrong" 3.9999, but I wrote a simple BASIC
> program on my beloved Tandy Model 100 and got the "correct" answer of
> 4. I was excited to see that my little first generation laptop gave
> better results than my state of the art (for the time) PC.
>
> Virgil
>
>
> On 02/10/2016 06:01 PM, [hidden email] wrote:
>> Virgil Arrington wrote:
>>> Ken Springer wrote
>>>> I remember years ago when Intel turned out a chip that had an error in
>>>> it's math calculations.  It was a rare happening, but when they
>>>> finally admitted it publicly, trying to say it wasn't important do to
>>>> the rare occurrence, it did not go over well at all! <G>
>>>>
>>>
>>> About 25 years ago, I was the treasurer of my children's preschool. I
>>> created a spreadsheet to calculate paychecks, and I found that the
>>> paycheck was consistently off by .01 (a penny). It drove me nuts. As it
>>> turned out, one part of the calculation required the division of 28 by
>>> 7, which every third grader knows is 4. Well, my spreadsheet gave an
>>> answer of 3.9999999999_. By itself, it wasn't a big problem, but later
>>> in the chain of operations, the 3.99999_ produced a result that rounded
>>> *down* to the nearest penny instead of *up*, which it would have
>>> done if
>>> the 28/7 had resulted in 4 instead of 3.9999. I complained to a
>>> computer
>>> friend of mine who tried to explain that the computer's answer was more
>>> "precise" than my mental math of 28/7=4. I didn't buy it.
>>
>> I wouldn't say 3.9999999... is more precise, but it sounds like your
>> problem is related to the precision of floating-point numbers. 1/7,
>> when represented in binary, is a recurring fraction 0.001001001...
>> (like how 1/3 is 0.3333... in decimal), so cannot be represented
>> precisely in binary with a finite number of bits (just as you can add
>> as many '3's as you like to 0.3333, but it still doesn't exactly
>> represent 1/3).
>>
>> I don't think there should be a problem with calculating 28/7 = 4 as
>> a single floating point operation, but if the calculation was done
>> (either in the way your formula was expressed or the way the
>> application processed it) as (1/7)*28, that may well give a slightly
>> inaccurate result due to rounding of the (1/7). A bit like
>> calculating 1/3 to 0.333, then multiplying that by 12 to get 3.996
>> instead of 4. If using a round-down function, and the result was
>> slightly less than 4, it would round down to 3. I guess the solution
>> was to round to the nearest integer.
>>
>>> I learned a valuable lesson in blindly accepting a computer's
>>> calculation simply because it was made by a computer.
>>
>> Indeed. They do exactly what they're told by a combination of
>> hardware, software and user input - but for various reasons that
>> might not amount to what you thought you were telling it to do.
>>
>> Mark.
>>
>>
>
>


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Brian Barker Brian Barker
Reply | Threaded
Open this post in threaded view
|

Re: Currency calculations [was: Avery 8167 label printing]

In reply to this post by Cuyahoga Falls
At 15:18 10/02/2016 -0500, Virgil Arrington wrote:

>About 25 years ago, I was the treasurer of my children's preschool.
>I created a spreadsheet to calculate paychecks, and I found that the
>paycheck was consistently off by .01 (a penny). It drove me nuts. As
>it turned out, one part of the calculation required the division of
>28 by 7, which every third grader knows is 4. Well, my spreadsheet
>gave an answer of 3.9999999999_. By itself, it wasn't a big problem,
>but later in the chain of operations, the 3.99999_ produced a result
>that rounded *down* to the nearest penny instead of *up*, which it
>would have done if the 28/7 had resulted in 4 instead of 3.9999. I
>complained to a computer friend of mine who tried to explain that
>the computer's answer was more "precise" than my mental math of
>28/7=4. I didn't buy it. I learned a valuable lesson in blindly
>accepting a computer's calculation simply because it was made by a computer.

I strongly suspect that you didn't, in fact, try to divide 28 by 4 -
which your spreadsheet would have got right!

Currency amounts are often expressed in whole pounds or dollars or
whatever, with pence or cents as a fraction of the basic currency
unit. But these fractions are deceptive: you simply don't want them
to be handled the way they are stated. If, for example, you have the
value $1.23 and halve it, you don't want the result to be $0.615. The
amounts may look like what programmers call "real" or
"floating-point" values, but they are actually *integer* values: that
$1.23 is better thought of as 123 cents - with no fractional part present.

Spreadsheet values are always real rather than integer, so you have
to take care with how you calculate with them. If you halve $1.23
(properly formatted as Currency) in a spreadsheet, the result will be
helpfully rounded in the display to $0.62. But the underlying value
will still be the correct result of 0.615. You need to be alert to
this situation in order to use spreadsheets successfully. You have a
number of options, and your choice may depend on circumstances:
o You may decide to retain the underlying value (although the
displayed value will still be rounded).
o You may round or truncate the value explicitly in your formula.
o You may choose to tick the option at Tools | Options... |
LibreOffice Calc | Calculate | Precision as shown.

Depending on your choice, doubling the displayed value of $0.62 may
produce $1.23 or $1.24. Both of these results may be helpful in
different circumstances. It is perfectly possible to carry out
accounting calculations in a spreadsheet providing they are done sensitively.

So what was happening in your case? Well, my guess is that the value
you were dividing by 4 was not the integer 28 but instead some
currency amount ending in 28 cents. If you express this
conventionally as $X.28, you are calculating with a floating-point
value having a fractional part of 0.28. Now although this fraction
terminates after two decimal digits, it is a recurring binary
fraction: 0.01000111101011100001... - with those twenty fractional
binary digits recurring indefinitely. It can only be that this value
is either truncated or rounded in a cell value. So if you choose to
use a spreadsheet conventionally - and here's the important point -
an amount of $X.28 is *already* stored only approximately. This is
the genuine source of your problem - not any subsequent division by 4.

At 18:14 10/02/2016 -0500, Virgil Arrington wrote:
>What I found interesting was that, in the spreadsheet, I got the
>"wrong" 3.9999, but I wrote a simple BASIC program on my beloved
>Tandy Model 100 and got the "correct" answer of 4. I was excited to
>see that my little first generation laptop gave better results than
>my state of the art (for the time) PC.

Well, we cannot know how you programmed this, but in Basic you may
have been forced either to use integer values - in which case you
would have represented $1.28 as 128 in cents, avoiding the problem -
or else to attend to the rounding explicitly. However you did this,
you were probably alert to the very problem of which you needed to be
aware in the spreadsheet version. The difference will not have been
because your simpler hardware was somehow better at doing elementary
arithmetic than your flashy new PC.

At 19:55 10/02/2016 -0700, Ken Springer wrote:
>I wouldn't buy it either. I don't care how someone tries to explain
>it, the result is wrong. Pure and simple. Just try pulling that
>response on a grade school teacher, and you're going home with an
>"F". How something can be more "precise" than the correct answer is
>beyond me. Wrong is wrong, I don't care how somebody wishes to justify it.

Sadly, all this attitude achieves is that you are never going to be
able to understand what is happening or to use spreadsheets reliably.
That is unfortunate, of course.

I trust this helps.

Brian Barker


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

James Knott James Knott
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

In reply to this post by steveedmonds
On 02/11/2016 03:33 AM, Steve Edmonds wrote:
> And there is the distinction between precision and accuracy. You can
> be very precisely inaccurate.

I guess you've never studied Calculus, where the answer often
approaches, but never actually reaches some value.  You can get closer
and closer, but never actually get that value.  ;-)


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Cuyahoga Falls Cuyahoga Falls
Reply | Threaded
Open this post in threaded view
|

Re: Currency calculations [was: Avery 8167 label printing]

In reply to this post by Brian Barker
Thanks for the tip, but back in 1989 when this was all happening, I'm
not sure that my DOS spreadsheet even had the ability to display numbers
as "currency". I certainly made no attempt to do so, even if it were
possible. They were just numbers and, yes, integers, and no, the
spreadsheet didn't get 28 divided by 7 correct.

I have learned, however, as you point out, that how numbers are
displayed is not the same as what they are. For example, you can't
"round" a number in a spreadsheet by simply reducing the number of
decimal places displayed in a cell. The underlying number remains
unrounded and further calculations with it might produce undesired
results. When working with currency, I've developed the habit of
probably overusing the the "@round" function at each step of a complex
calculation just to ensure desired results.

Virgil



On 02/11/2016 04:16 AM, Brian Barker wrote:

> At 15:18 10/02/2016 -0500, Virgil Arrington wrote:
>> About 25 years ago, I was the treasurer of my children's preschool. I
>> created a spreadsheet to calculate paychecks, and I found that the
>> paycheck was consistently off by .01 (a penny). It drove me nuts. As
>> it turned out, one part of the calculation required the division of
>> 28 by 7, which every third grader knows is 4. Well, my spreadsheet
>> gave an answer of 3.9999999999_. By itself, it wasn't a big problem,
>> but later in the chain of operations, the 3.99999_ produced a result
>> that rounded *down* to the nearest penny instead of *up*, which it
>> would have done if the 28/7 had resulted in 4 instead of 3.9999. I
>> complained to a computer friend of mine who tried to explain that the
>> computer's answer was more "precise" than my mental math of 28/7=4. I
>> didn't buy it. I learned a valuable lesson in blindly accepting a
>> computer's calculation simply because it was made by a computer.
>
> I strongly suspect that you didn't, in fact, try to divide 28 by 4 -
> which your spreadsheet would have got right!
>
> Currency amounts are often expressed in whole pounds or dollars or
> whatever, with pence or cents as a fraction of the basic currency
> unit. But these fractions are deceptive: you simply don't want them to
> be handled the way they are stated. If, for example, you have the
> value $1.23 and halve it, you don't want the result to be $0.615. The
> amounts may look like what programmers call "real" or "floating-point"
> values, but they are actually *integer* values: that $1.23 is better
> thought of as 123 cents - with no fractional part present.
>
> Spreadsheet values are always real rather than integer, so you have to
> take care with how you calculate with them. If you halve $1.23
> (properly formatted as Currency) in a spreadsheet, the result will be
> helpfully rounded in the display to $0.62. But the underlying value
> will still be the correct result of 0.615. You need to be alert to
> this situation in order to use spreadsheets successfully. You have a
> number of options, and your choice may depend on circumstances:
> o You may decide to retain the underlying value (although the
> displayed value will still be rounded).
> o You may round or truncate the value explicitly in your formula.
> o You may choose to tick the option at Tools | Options... |
> LibreOffice Calc | Calculate | Precision as shown.
>
> Depending on your choice, doubling the displayed value of $0.62 may
> produce $1.23 or $1.24. Both of these results may be helpful in
> different circumstances. It is perfectly possible to carry out
> accounting calculations in a spreadsheet providing they are done
> sensitively.
>
> So what was happening in your case? Well, my guess is that the value
> you were dividing by 4 was not the integer 28 but instead some
> currency amount ending in 28 cents. If you express this conventionally
> as $X.28, you are calculating with a floating-point value having a
> fractional part of 0.28. Now although this fraction terminates after
> two decimal digits, it is a recurring binary fraction:
> 0.01000111101011100001... - with those twenty fractional binary digits
> recurring indefinitely. It can only be that this value is either
> truncated or rounded in a cell value. So if you choose to use a
> spreadsheet conventionally - and here's the important point - an
> amount of $X.28 is *already* stored only approximately. This is the
> genuine source of your problem - not any subsequent division by 4.
>
> At 18:14 10/02/2016 -0500, Virgil Arrington wrote:
>> What I found interesting was that, in the spreadsheet, I got the
>> "wrong" 3.9999, but I wrote a simple BASIC program on my beloved
>> Tandy Model 100 and got the "correct" answer of 4. I was excited to
>> see that my little first generation laptop gave better results than
>> my state of the art (for the time) PC.
>
> Well, we cannot know how you programmed this, but in Basic you may
> have been forced either to use integer values - in which case you
> would have represented $1.28 as 128 in cents, avoiding the problem -
> or else to attend to the rounding explicitly. However you did this,
> you were probably alert to the very problem of which you needed to be
> aware in the spreadsheet version. The difference will not have been
> because your simpler hardware was somehow better at doing elementary
> arithmetic than your flashy new PC.
>
> At 19:55 10/02/2016 -0700, Ken Springer wrote:
>> I wouldn't buy it either. I don't care how someone tries to explain
>> it, the result is wrong. Pure and simple. Just try pulling that
>> response on a grade school teacher, and you're going home with an
>> "F". How something can be more "precise" than the correct answer is
>> beyond me. Wrong is wrong, I don't care how somebody wishes to
>> justify it.
>
> Sadly, all this attitude achieves is that you are never going to be
> able to understand what is happening or to use spreadsheets reliably.
> That is unfortunate, of course.
>
> I trust this helps.
>
> Brian Barker
>
>


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Gary Dale Gary Dale
Reply | Threaded
Open this post in threaded view
|

Re: Currency calculations [was: Avery 8167 label printing]

On 11/02/16 09:37 AM, Virgil Arrington wrote:

> Thanks for the tip, but back in 1989 when this was all happening, I'm
> not sure that my DOS spreadsheet even had the ability to display
> numbers as "currency". I certainly made no attempt to do so, even if
> it were possible. They were just numbers and, yes, integers, and no,
> the spreadsheet didn't get 28 divided by 7 correct.
>
> I have learned, however, as you point out, that how numbers are
> displayed is not the same as what they are. For example, you can't
> "round" a number in a spreadsheet by simply reducing the number of
> decimal places displayed in a cell. The underlying number remains
> unrounded and further calculations with it might produce undesired
> results. When working with currency, I've developed the habit of
> probably overusing the the "@round" function at each step of a complex
> calculation just to ensure desired results.
>
> Virgil
>
>
There were stories back in the 1970s about programmers taking advantage
of the binary/floating point rounding errors to transfer a penny here
and there into their own accounts. With huge numbers of transactions
each day, the pennies added up very quickly.

COBOL actually had features that let you do arithmetic in decimal digits
with the decimal point being a display item, not an actual fractional
part of a number, so that the results would be exactly what they were if
you did the calculations by hand.

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Robert Holtzman Robert Holtzman
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

In reply to this post by James Knott
On Thu, Feb 11, 2016 at 07:21:31AM -0500, James Knott wrote:
> On 02/11/2016 03:33 AM, Steve Edmonds wrote:
> > And there is the distinction between precision and accuracy. You can
> > be very precisely inaccurate.
>
> I guess you've never studied Calculus, where the answer often
> approaches, but never actually reaches some value.  You can get closer
> and closer, but never actually get that value.  ;-)

Recall the old joke about a man and woman approaching each other
asymptotically. The mathematician says they never meet. The engineer says
that they get close enough for all practical purposes.

--
Bob Holtzman
A man is a man who will fight with a sword or
conquer Mt. Everest in snow. But the bravest of all
owns a '34 Ford and tries for six thousand in low.

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

steveedmonds steveedmonds
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

In reply to this post by James Knott


On 12/02/16 1:21 AM, James Knott wrote:
> On 02/11/2016 03:33 AM, Steve Edmonds wrote:
>> And there is the distinction between precision and accuracy. You can
>> be very precisely inaccurate.
> I guess you've never studied Calculus, where the answer often
> approaches, but never actually reaches some value.  You can get closer
> and closer, but never actually get that value.  ;-)
>
>
Sounds like life.
A bit off topic One of the things I did like about calculus is that it
models so much of what changes about us. A real eye opener, when I first
started applying it to real life situations it was a bit like seeing all
that code in the matrix (some years before the matrix, cell phones and PCs).

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
libreoffice-ml.mbourne libreoffice-ml.mbourne
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

In reply to this post by Cuyahoga Falls
Perhaps the BASIC code was only displaying the number to a few decimal
places. In C, printf defaults to 6 decimal places, which isn't enough to
show the actual result as any different from the ideal result.

It's also possible that the spreadsheet was doing something more
complicated internally than just 28*(1/7). Playing around with an
example in C, I can see the error in representing (1/7), but multiplying
that by 28 gives exactly 4:
                 Decimal                           In-memory
         (1/7) = 0.142857149243354797363281250000  0x3e124925
      28*(1/7) = 4.000000000000000000000000000000  0x40800000

On the other hand, storing 1/490 in a float, then storing the result of
multiplying that by 70 (should be the same as 1/7), then storing the
result of multiplying that by 28, gives 3.99999976...:
                 Decimal                           In-memory
       (1/490) = 0.002040816238150000572204589844  0x3b05bf37
    70*(1/490) = 0.142857134342193603515625000000  0x3e124924
28*70*(1/490) = 3.999999761581420898437500000000  0x407fffff

I'm not suggesting that's exactly what the spreadsheet was doing, but it
shows that slight changes to the detail of the calculation (which
wouldn't affect the result with unlimited precision) can have an effect
on whether the result is equal to or slightly more or less than the
expected result.

Mark.


Virgil Arrington wrote:

> Thanks for the explanation. Oddly enough, it makes some sense, even to
> my non-techy brain. What I found interesting was that, in the
> spreadsheet, I got the "wrong" 3.9999, but I wrote a simple BASIC
> program on my beloved Tandy Model 100 and got the "correct" answer of 4.
> I was excited to see that my little first generation laptop gave better
> results than my state of the art (for the time) PC.
>
> Virgil
>
>
> On 02/10/2016 06:01 PM, [hidden email] wrote:
>> Virgil Arrington wrote:
>>> Ken Springer wrote
>>>> I remember years ago when Intel turned out a chip that had an error in
>>>> it's math calculations.  It was a rare happening, but when they
>>>> finally admitted it publicly, trying to say it wasn't important do to
>>>> the rare occurrence, it did not go over well at all! <G>
>>>>
>>>
>>> About 25 years ago, I was the treasurer of my children's preschool. I
>>> created a spreadsheet to calculate paychecks, and I found that the
>>> paycheck was consistently off by .01 (a penny). It drove me nuts. As it
>>> turned out, one part of the calculation required the division of 28 by
>>> 7, which every third grader knows is 4. Well, my spreadsheet gave an
>>> answer of 3.9999999999_. By itself, it wasn't a big problem, but later
>>> in the chain of operations, the 3.99999_ produced a result that rounded
>>> *down* to the nearest penny instead of *up*, which it would have done if
>>> the 28/7 had resulted in 4 instead of 3.9999. I complained to a computer
>>> friend of mine who tried to explain that the computer's answer was more
>>> "precise" than my mental math of 28/7=4. I didn't buy it.
>>
>> I wouldn't say 3.9999999... is more precise, but it sounds like your
>> problem is related to the precision of floating-point numbers. 1/7,
>> when represented in binary, is a recurring fraction 0.001001001...
>> (like how 1/3 is 0.3333... in decimal), so cannot be represented
>> precisely in binary with a finite number of bits (just as you can add
>> as many '3's as you like to 0.3333, but it still doesn't exactly
>> represent 1/3).
>>
>> I don't think there should be a problem with calculating 28/7 = 4 as a
>> single floating point operation, but if the calculation was done
>> (either in the way your formula was expressed or the way the
>> application processed it) as (1/7)*28, that may well give a slightly
>> inaccurate result due to rounding of the (1/7). A bit like calculating
>> 1/3 to 0.333, then multiplying that by 12 to get 3.996 instead of 4.
>> If using a round-down function, and the result was slightly less than
>> 4, it would round down to 3. I guess the solution was to round to the
>> nearest integer.
>>
>>> I learned a valuable lesson in blindly accepting a computer's
>>> calculation simply because it was made by a computer.
>>
>> Indeed. They do exactly what they're told by a combination of
>> hardware, software and user input - but for various reasons that might
>> not amount to what you thought you were telling it to do.
>>
>> Mark.
>>
>>
>
>


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
snowshed snowshed
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

In reply to this post by Gary Dale
On 2/10/16 9:32 PM, Gary Dale wrote:

> On 10/02/16 10:53 PM, Ken Springer wrote:
>> On 2/10/16 4:27 PM, Gary Dale wrote:
>>> On 10/02/16 12:01 PM, Ken Springer wrote:
>>>> On 2/10/16 8:28 AM, Gary Dale wrote:
>>>>> On 09/02/16 11:39 PM, Ken Springer wrote:
>>>>>> On 2/9/16 2:23 PM, Gary Dale wrote:
>>>>>>> On 09/02/16 03:23 PM, Dave Liesse wrote:
>>>>>>>>
>>
>> <snip>
>>
>>> PDF is a great way to exchange documents but it has an interesting print
>>> option (usually) of shrinking to fit the printer margins. If you send a
>>> PDF label set, you need to remind the recipient to print them full size.
>>> I've run into this problem several times where my carefully crafted PDFs
>>> aren't printed the way I designed them.
>>
>> In this case, IMO, the creator of the PDF should be aware of the
>> potential margin issue and set them accordingly.  So far, I've never
>> been burned that I know of by using .5" margins except with the top
>> margin of the 8167 labels.
>>
>> So there should be no need for shrink to fit unless we are talking a
>> totally different page size.
>>
>> But it's awful hard to break people's mindset and get them to switch
>> to PDF.  "Oh, if we are going to share and work with the same thing,
>> we both have to have MS Word."  Or WordPerfect.  Or Lotus' word
>> processor in the old days, I can't remember the name. At one time,
>> this was absolutely true.  But it's no longer a mandatory thing with
>> PDF on the scene.
>>
>> There will be situations where where Word, or Excel, or ???????? will
>> be required.  But it's because that software is already in use across
>> the enterprise.  It's not because it's the only software that will do
>> the job.
>
> That's not the issue. Sometimes you want something to occupy the full
> page for professional printing but people use their home printers instead.

Agreed, you need the bleed area.  But in this case of labels off the
shelf, using a software's built in template that is correct when
measured with a ruler, telling the software to shrink to fit shouldn't
have any effect.

I just did a business card design that needed a bleed area.  Actually
came out with the right colors!   LOL

> As for using the same software, that doesn't solve problems if the
> person doesn't have the same fonts installed that you do. The PDF format
> removes the requirement to stick to common fonts.
>
> Similarly the ISO standard Open Document formats that LibreOffice uses
> allow documents to used by other programs, including the M$ ones. They
> may not look the same, but will at least be exchangeable and editable.
>
>>
>>>
>>>>
>>>>>>
>>>>>>> There used to be a problem with multi-column labels but they seem to
>>>>>>> have redone the label specification to correct that. When creating
>>>>>>> labels, there is "Format" tab that lets you adjust the label
>>>>>>> properties.
>>>>>>> In its new incarnation, it is easy to use and gives you exactly
>>>>>>> what you
>>>>>>> need to adjust the properties of incorrectly specified common label
>>>>>>> formats down to 1/100 of an inch.
>>>>>>
>>>>>> In the end, I'll probably do this.
>>>>>>
>>>>>>> You can specify the top margin, label height and vertical pitch (the
>>>>>>> last two may be different if there is space between the labels)
>>>>>>> and do
>>>>>>> the same for the left margin, label width and horizontal pitch. They
>>>>>>> also allow you to specify the page size and the number of rows and
>>>>>>> columns.
>>>>>>>
>>>>>>> If you think a label isn't defined correctly, fix it. Also, file
>>>>>>> a bug
>>>>>>> report so that the developers can fix it for everyone. It's
>>>>>>> better to
>>>>>>> light a candle or two than to curse the darkness.
>>>>>>
>>>>>> In this case, the label spec is correct.  Font design will have to
>>>>>> have a factor in this someway too, I suspect.
>>>>>
>>>>> It shouldn't unless LO calculates the position of the next label
>>>>> relative to the end of the previous text. It would seem more natural
>>>>> (and simpler) to calculate in absolute terms.
>>>>
>>>> Upon retrospect, I agree.  But it is something you have to be
>>>> cognizant of when designing the label, as it can affect the apparent
>>>> vertical centering of text on the label.  Which can effect what you
>>>> think may be happening with label output.  In my case, the label
>>>> includes a graphic, which is unaffected by text positioning. Makes it
>>>> easy to figure out where the problem is likely to be.
>>>>
>>>> Another overall negative effect of this problem is, you have to ask
>>>> yourself, if this is broken, what else in the suite is broken?
>>>> Especially if you are using LO to make a living.  Is there another
>>>> feature I use in Writer that doesn't work correctly?  What if one or
>>>> two functions in the spreadsheet calculate incorrectly?  What if Base
>>>> occasionally mangles your data?
>>>>
>>>> I remember years ago when Intel turned out a chip that had an error in
>>>> it's math calculations.  It was a rare happening, but when they
>>>> finally admitted it publicly, trying to say it wasn't important do to
>>>> the rare occurrence, it did not go over well at all! <G>
>>>>
>>>
>>> I've yet to find software that is perfect (except of course for what I
>>> develop  ;)  ).  Big suites like LO will have the occasional bug but
>>> I've never found one that was more than an annoyance.
>>
>> It's an annoyance if you can find a workaround.  It's a problem if
>> there's no workaround, and it's something you need to get your job done.
>>
>> And, if it was something I produced, I won't be happy until it's
>> fixed.  "Close enough" just doesn't work for me in a lot of cases.
>
> You did find a workaround though. As for perfection, the universe
> wouldn't exist if there was such a thing.

Unfortunately,  the work around only works for me.  If this was
something that needed to be sent to someone else, the workaround is
probably useless.



--
Ken
Mac OS X 10.8.5
Firefox 44.0
Thunderbird 38.0.1
"My brain is like lightning, a quick flash
      and it's gone!"


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
libreoffice-ml.mbourne libreoffice-ml.mbourne
Reply | Threaded
Open this post in threaded view
|

Re: Avery 8167 label printing

In reply to this post by snowshed
Ken Springer wrote:

> On 2/10/16 3:19 PM, [hidden email] wrote:
>> Ken Springer wrote:
>>> Slippage in the rollers is what I was thinking of.
>>>
>>> In my case, the error is consistent, so slippage is not problem.
>>>
>>> Telling the printer where to actually start the printing appears to be
>>> the issue.  We'll call it the top margin for convenience, but even that
>>> has it's own issues.  Since the driver is TWAIN, the brand of printer
>>> shouldn't make a difference as long as the printer manufacturer doesn't
>>> screw up the driver.
>>>
>>> Time to "expand our horizons".  (Sounds like a motivational speaker,
>>> doesn't it?   LOL)
>>>
>>> LO's built-in template, displayed on the screen, is correct.  The
>>> paper's top margin is .5" on the screen and in real life.  Positioning
>>> of the text is also correct, as displayed on the screen.
>>>
>>> Only printing is in error.
>>>
>>> Now...  Suppose you are creating X number of label designs for someone
>>> else.  They don't have LO, how to you get the labels to them?  Today, I
>>> think almost everyone's answer would be PDF.
>>
>> You may already realise, but in case not... Adobe Reader has an option
>> to "Shrink oversized pages" when printing.
>
> Every PDF reader I've toyed with has  that option for scaling.  Useful
> if you receive something that was created for 11 X 17 paper, and all you
> have is 8.5 X11.  In which case, I would expect a bit of error, not to
> mention difficulty in reading text that may be on the page.
>
>> You might not expect that to
>> do anything when printing an A4 PDF printing onto A4 paper, but it
>> actually shrinks the page slightly to allow for the non-printable
>> margins around the page. To get a 1:1 scale print you have to select
>> "Actual size". It remembers the last setting you use, so you have to
>> remember to check what's it's set to each time.
>
> I would submit, that the person who created the PDF, should have
> considered non-printable margins.  Which is why I always use margins
> that I'm sure all printers can handle, at least to the best of my
> knowledge.

I'd agree with that. Pretty much all PDFs I've seen do have a margin
between the content and the edge of the page, and can be printed at
actual size without problem. It's useful, as you say, if you need to
print an 11x17 document on 8.5x11 paper (or in my case usually A3 on
A4), but rather annoying when it's then set by default next time and
shrinks an 8.5x11 (or A4) document slightly. I think it's the default on
a fresh install of Adobe Reader so some people might not even notice it.

>>> Fair enough, but that doesn't work either.  If you create the PDF with
>>> the default template settings, which are correct, the resulting PDF file
>>> is also in error.  I tried it.  Same vertical offset issue.
>>
>> Is the vertical offset incorrect on screen as well as when printed? When
>> I first read that, I thought you meant it was wrong on-screen as well,
>> but from your discussion below it sounds like the PDF is displayed with
>> the correct margin, but prints with the wrong margin?
>
> If the onscreen display of the margins for 8167 labels is correct, the
> printed output is incorrect, from both LO and PDF.  If the onscreen
> margins are incorrect (to the needed amount of course), the printed
> output is correct, from both LO and PDF.
>
>>> So you change the top margin, create the PDF, and yep, labels print
>>> correctly.
>>>
>>> What's wrong with this?
>>>
>>> In the above scenario, the recipient of the PDF may/can/will look at the
>>> labels before printing them, to see if they are correct.  (If they
>>> don't, they aren't doing their job.)  Guess what?  They'll see the top
>>> margin error, more easily spotted if you have a vertical ruler option.
>>> If you send a PDF based on the correct template (the one supplied by
>>> LO), the printing will be off.  If you send a PDF based on a modified
>>> template, the visual display on the screen will be off.
>>
>> So if you have a PDF which displays on screen with the correct margin,
>> but when printed it has the wrong margin?
>
> Yep.   <G>
>
>> To get it to print with the
>> correct margin, you have to produce a PDF which displays with an
>> incorrect margin?
>
> Yep.
>
> < Assuming you're printing the PDF at actual size, that
>> would suggest the printer or its driver is in error (unless your PDF
>> reader has the same issue as LibreOffice). Once LibreOffice has created
>> a PDF, it has nothing to do with any difference between how the PDF
>> reader displays and prints it.
>
> Unless the error is embedded in the PDF.   :-)

I'm not sure that there's anything in the PDF format to specify
different margins for display and printing, but I may be wrong. It's
intended as a page layout format, specifying the position of each item
so that it's displayed and printed consistently between systems. As I
understand it, PDF doesn't even have a concept of paragraphs - they're
just separate lines which happen to be positioned one below another.

> I hadn't considered the printer driver to be the problem, since the
> other size label does not exhibit this issue.  A .5" margin is a .5"
> margin.   :-)

That is odd... Do both templates have a 0.5" margin? If you put the same
line of text into the first label of both templates, does it appear the
same distance from the top of the page in both cases (when viewed on
screen)? Or does that line appear slightly lower in one than the other
(perhaps because there's an additional margin between the top of label
and its content)?

Do both templates have the same horizontal margins? Perhaps something
(maybe the printer driver) is scaling to fit the horizontal width within
the printable area of the page; some sheets of labels go quite close to
the edges.

It may be worth looking through all the options offered by your printer,
in case there's anything there related to scaling, fit-to-page, scaling
A4 to fit on letter paper (or letter on A4), etc. I'm not sure if it's
the same on Mac, but on Windows LibreOffice those options can be found
at File > Print > (Select printer) > Properties. If there's an option
for borderless printing, it might be worth trying that too.

>> If you open a PDF created from a completely different application, does
>> that also print with different margins than when displayed on-screen?
>
> Yep.  Just tried Word 2011 on this Mac, same printing error.  Margin on
> the screen is correct, printed margin is not.  Which does point to the
> printer driver as the possible source of the problem.

It may be worth looking on the printer manufacturer's website to see if
an updated driver is available.

> OT, but I noticed that the 0 point on the vertical ruler in Office is at
> the top margin, not the top of the paper.  Resulting in the ruler saying
> the letter sized paper being 10.5" long.   LOL

It probably makes sense for the horizontal ruler to start at the margin,
since you're more likely to want to specify indents etc. relative to the
edge of the text rather than the page (the distinction is more important
if odd and even pages have different margins). I guess the vertical
ruler is just consistent with that. To be honest, I don't think I use
the vertical ruler much.

>> Can you try printing your LibreOffice document and/or PDF on a different
>> printer? Rather than wasting labels, you could of course print on plain
>> paper and hold it up against the labels ;o)
>
> Wish I could, but my inkjet does not want to feed paper.  I suspect the
> rubber feed roller has hardened on the surface and no longer grabs the
> paper.  I used it so little, it's way down on the priority list to fix.

No problem, it was just another idea to narrow down the problem. Having
tried a different application with the same printer helps there.


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
12 « Prev