Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #91570 > unrolled thread

Using Python instead of Bash

Back to article view | Back to comp.lang.python

Contents

  Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-05-31 14:42 +0200
    Re: Using Python instead of Bash Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-05-31 16:02 +0200
      Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-05-31 18:36 +0200
    Re: Using Python instead of Bash Cem Karan <cfkaran2@gmail.com> - 2015-05-31 10:14 -0400
      Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-05-31 18:58 +0200
    Re: Using Python instead of Bash Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-31 11:05 -0400
      Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-05-31 19:06 +0200
        Re: Using Python instead of Bash Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-31 20:53 -0400
          Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-06-01 11:25 +0200
        Re: Using Python instead of Bash Laura Creighton <lac@openend.se> - 2015-06-01 09:11 +0200
    Re: Using Python instead of Bash Ethan Furman <ethan@stoneleaf.us> - 2015-05-31 22:08 -0700
    Re: Using Python instead of Bash Larry Hudson <orgnut@yahoo.com> - 2015-06-01 00:56 -0700
      Re: Using Python instead of Bash Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-06-01 11:06 +0300
        Re: Using Python instead of Bash alister <alister.nospam.ware@ntlworld.com> - 2015-06-01 09:07 +0000
          Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-06-01 12:44 +0200
            Re: Using Python instead of Bash Laura Creighton <lac@openend.se> - 2015-06-01 17:44 +0200
              Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-06-01 18:44 +0200
                Re: Using Python instead of Bash Laura Creighton <lac@openend.se> - 2015-06-01 20:42 +0200
                  Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-06-01 21:57 +0200
                    Re: Using Python instead of Bash Laura Creighton <lac@openend.se> - 2015-06-01 22:42 +0200
                      Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-06-01 23:04 +0200
      Re: Using Python instead of Bash Cecil Westerhof <Cecil@decebal.nl> - 2015-06-01 11:11 +0200
        Re: Using Python instead of Bash Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 12:38 +0300
    Re: Using Python instead of Bash Grant Edwards <invalid@invalid.invalid> - 2015-06-01 14:51 +0000

Page 1 of 2  [1] 2  Next page →

#91570 — Using Python instead of Bash

I help someone that has problems reading. For this I take photo's of
text, use convert from ImageMagick to make a good contrast (original
paper is grey) and use lpr to print it a little bigger.

Normally I would implement this in Bash, but I thought it a good idea
to implement it in Python. This is my first try:
    import glob
    import subprocess

    treshold = 66
    count = 0
    for input in sorted(glob.glob('*.JPG')):
        count += 1
        output = '{0:02d}.png'.format(count)
        print('Going to convert {0} to {1}'.format(input, output))
        p = subprocess.Popen(['convert', '-threshold', '{0}%'.format(treshold), input, output])
        p.wait()
        print('Going to print {0}'.format(output))
        p = subprocess.Popen(['lpr', '-o', 'fit-to-page', '-o', 'media=A4', output])
        p.wait()

There have to be some improvements: display before printing,
possibility to change threshold, … But is this a good start, or should
I do it differently?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#91572

Cecil Westerhof <Cecil@decebal.nl> writes:

> I help someone that has problems reading. For this I take photo's of
> text, use convert from ImageMagick to make a good contrast (original
> paper is grey) and use lpr to print it a little bigger.

>     import glob
>     import subprocess
>
>     treshold = 66
>     count = 0
>     for input in sorted(glob.glob('*.JPG')):
>         count += 1
>         output = '{0:02d}.png'.format(count)
>         print('Going to convert {0} to {1}'.format(input, output))
>         p = subprocess.Popen(['convert', '-threshold', '{0}%'.format(treshold), input, output])
>         p.wait()
>         print('Going to print {0}'.format(output))
>         p = subprocess.Popen(['lpr', '-o', 'fit-to-page', '-o', 'media=A4', output])
>         p.wait()

Maybe using check_call() would be simpler, but it will, well, check for
the exit code of convert/lpr (which you should do anyway). And I would
call that variable "threshold" instead of "treshold".

(What I don't see is the advantage you find in writing such scripts in
python instead of sh, but I guess you have your own reasons.)

-- Alain.

[toc] | [prev] | [next] | [standalone]

#91583

Op Sunday 31 May 2015 16:02 CEST schreef Alain Ketterlin:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>
>> I help someone that has problems reading. For this I take photo's
>> of text, use convert from ImageMagick to make a good contrast
>> (original paper is grey) and use lpr to print it a little bigger.
>
>> import glob
>> import subprocess
>>
>> treshold = 66 count = 0 for input in sorted(glob.glob('*.JPG')):
>> count += 1 output = '{0:02d}.png'.format(count) print('Going to
>> convert {0} to {1}'.format(input, output)) p =
>> subprocess.Popen(['convert', '-threshold', '{0}%'.format(treshold),
>> input, output]) p.wait() print('Going to print {0}'.format(output))
>> p = subprocess.Popen(['lpr', '-o', 'fit-to-page', '-o', 'media=A4',
>> output]) p.wait()
>
> Maybe using check_call() would be simpler, but it will, well, check
> for the exit code of convert/lpr (which you should do anyway).

That is a lot better yes. I did not like that I needed two calls.


> And I would call that variable "threshold" instead of "treshold".

Yep, I saw the mistake after posting. :-(


> (What I don't see is the advantage you find in writing such scripts
> in python instead of sh, but I guess you have your own reasons.)

Several.

The first is that I want to get some Python experience.

But later on I want to display the converted photo and if it is not
correct, change the threshold and convert it again with a new
threshold. 66% is good most of the time, but not always. Sometimes it
has to be bigger or smaller.

And after that I want to put a GUI around it.

So, that is why I am using Python.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91574

> I help someone that has problems reading. For this I take photo's of
> text, use convert from ImageMagick to make a good contrast (original
> paper is grey) and use lpr to print it a little bigger.
> 
> Normally I would implement this in Bash, but I thought it a good idea
> to implement it in Python. This is my first try:
>    import glob
>    import subprocess
> 
>    treshold = 66
>    count = 0
>    for input in sorted(glob.glob('*.JPG')):
>        count += 1
>        output = '{0:02d}.png'.format(count)
>        print('Going to convert {0} to {1}'.format(input, output))
>        p = subprocess.Popen(['convert', '-threshold', '{0}%'.format(treshold), input, output])
>        p.wait()
>        print('Going to print {0}'.format(output))
>        p = subprocess.Popen(['lpr', '-o', 'fit-to-page', '-o', 'media=A4', output])
>        p.wait()
> 
> There have to be some improvements: display before printing,
> possibility to change threshold, … But is this a good start, or should
> I do it differently?


As a first try, I think its pretty good, but to really answer your question, I think we could use a little more information.  

- Are you using python 2, or python 3?  There are slightly easier ways to do this using concurrent.futures objects, but they are only available under python 3. (See https://docs.python.org/3/library/concurrent.futures.html)

- In either case, subprocess.call(), subprocess.check_call(), or subprocess.check_output() may be easier to use.  That said, your code is perfectly fine!  The only real difference is that subprocess.call() will automatically wait for the call to complete, so you don't need to use p.wait() from above.  (See https://docs.python.org/2.7/library/subprocess.html, and https://docs.python.org/3/library/subprocess.html) 



The following codes does the conversion in parallel, and submits the jobs to the printer serially.  That should ensure that the printed output is also in sorted order, but you might want to double check before relying on it too much.  The major problem with it is that you can't display the output before printing; since everything is running in parallel, you'll have race conditions if you try.  **I DID NOT TEST THIS CODE, I JUST TYPED IT OUT IN MY MAIL CLIENT!**  Please test it carefully before relying on it!

"""
import subprocess
import concurrent.futures
import glob
import os.path

_THRESHOLD = 66

def _collect_filenames():
    files = glob.glob('*.JPG')

    # I build a set of the real paths so that if you have 
    # symbolic links that all point to the same file, they
    # they are automatically collapsed to a single file
    real_files = {os.path.realpath(x) for x in files}
    base_files = [os.path.splitext(x)[0] for x in real_files]
    return base_files

def _convert(base_file_name):
    """
    This code is slightly different from your code.  Instead
    of using numbers as names, I use the base name of file and
    append '.png' to it.  You may need to adjust this to ensure
    you don't overwrite anything.
    """
    input = base_file_name + ".JPG"
    output = base_file_name + ".png"
    subprocess.call(['convert', '-threshold', '{0}%'.format(_THRESHOLD), input, output])

def _print_files_in_order(base_files):
    base_files.sort()
    for f in base_files:
        output = f + ".png"
        subprocess.call(['lpr', '-o', 'fit-to-page', '-o', 'media=A4', output])

def driver():
    base_files = _collect_filenames()

    # If you use an executor as a context manager, then the
    # executor will wait until all of the submitted jobs finish
    # before it returns.  The submitted jobs will execute in
    # parallel.
    with concurrent.futures.ProcessPoolExecutor() as executor:
        for f in base_files:
            executor.submit(_convert_and_print, f)

    _print_files_in_order(base_files)
"""

Thanks,
Cem Karan

[toc] | [prev] | [next] | [standalone]

#91584

Op Sunday 31 May 2015 16:14 CEST schreef Cem Karan:

>> I help someone that has problems reading. For this I take photo's
>> of text, use convert from ImageMagick to make a good contrast
>> (original paper is grey) and use lpr to print it a little bigger.
>>
>> Normally I would implement this in Bash, but I thought it a good
>> idea to implement it in Python. This is my first try: import glob
>> import subprocess
>>
>> treshold = 66 count = 0 for input in sorted(glob.glob('*.JPG')):
>> count += 1 output = '{0:02d}.png'.format(count) print('Going to
>> convert {0} to {1}'.format(input, output)) p =
>> subprocess.Popen(['convert', '-threshold', '{0}%'.format(treshold),
>> input, output]) p.wait() print('Going to print {0}'.format(output))
>> p = subprocess.Popen(['lpr', '-o', 'fit-to-page', '-o', 'media=A4',
>> output]) p.wait()
>>
>> There have to be some improvements: display before printing,
>> possibility to change threshold, … But is this a good start, or
>> should I do it differently?
>
>
> As a first try, I think its pretty good, but to really answer your
> question, I think we could use a little more information.
>
> - Are you using python 2, or python 3? There are slightly easier
>   ways to do this using concurrent.futures objects, but they are
>   only available under python 3. (See
>   https://docs.python.org/3/library/concurrent.futures.html)

In principal I am using Python 3, but I prefer it to work also under
Python 2.

concurrent.futures is definitely something to look at, but not in this
case I think. First of all the processing does not take much time.
Secondly the order of the printing is important. Lastly, it is not
done now, but the conversion should be checked and maybe done over
with another threshold.


> - In either case, subprocess.call(), subprocess.check_call(), or
>   subprocess.check_output() may be easier to use.

I am using subprocess.check_call now. Much better.


> The following codes does the conversion in parallel, and submits the
> jobs to the printer serially.

Not needed now, but I file it for later use. ;-)


> def _convert(base_file_name): """ This code is slightly different
> from your code. Instead of using numbers as names, I use the base
> name of file and append '.png' to it. You may need to adjust this to

The reason I use numbers is that what I am printing is a booklet. The
input is IMG_4769.JPG and then I find 01.png much better, because then
I know which page it is. :-D


Thanks for the quit interesting read.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91579

On Sun, 31 May 2015 14:42:02 +0200, Cecil Westerhof <Cecil@decebal.nl>
declaimed the following:

>I help someone that has problems reading. For this I take photo's of
>text, use convert from ImageMagick to make a good contrast (original
>paper is grey) and use lpr to print it a little bigger.
>
>Normally I would implement this in Bash, but I thought it a good idea
>to implement it in Python. This is my first try:

	<code snipped>

	My first impression is that all you did was convert BASH line for line
to Python -- and are still passing all the real work over to external
programs ("convert" and "lpr"), using subprocess... Instead of a BASH
script alternating between running command line utilities convert and lpr,
you have a BASH (or other) shell running a Python process and Python
alternating between a pair of command line utilities with all the overhead
of creating and terminating processes.

	I'll concede submitting jobs to a print queue probably does work easier
this way, but I'd have to ask if the "convert" could be performed using
actual Python -- the old Python Imaging Library -- PIL -- for example
(superseded, I think, by pillow)?

	Given that you do nothing between creating a subprocess and waiting for
it to exit, subprocess.Popen() could be overkill -- the simpler
subprocess.call() could be sufficient (heck, the old os.system() is
sufficient, but preference seems to be to ignore it for subprocess.call()
instead).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#91585

Op Sunday 31 May 2015 17:05 CEST schreef Dennis Lee Bieber:

> On Sun, 31 May 2015 14:42:02 +0200, Cecil Westerhof
> <Cecil@decebal.nl> declaimed the following:
>
>> I help someone that has problems reading. For this I take photo's
>> of text, use convert from ImageMagick to make a good contrast
>> (original paper is grey) and use lpr to print it a little bigger.
>>
>> Normally I would implement this in Bash, but I thought it a good
>> idea to implement it in Python. This is my first try:
>
> 	<code snipped>
>
> 	My first impression is that all you did was convert BASH line
> for line to Python -- and are still passing all the real work over
> to external programs ("convert" and "lpr"), using subprocess...
> Instead of a BASH script alternating between running command line
> utilities convert and lpr, you have a BASH (or other) shell running
> a Python process and Python alternating between a pair of command
> line utilities with all the overhead of creating and terminating
> processes.

That is true (the conversion). But there are two reasons for this.
- I want to get some experience with Python.
- I want to implement extra functionality, which would be easier with
Python as with Bash.

Also: I am thinking about using ipython3 instead of bash.


> 	I'll concede submitting jobs to a print queue probably does work
> easier this way, but I'd have to ask if the "convert" could be
> performed using actual Python -- the old Python Imaging Library --
> PIL -- for example (superseded, I think, by pillow)?

That is something to look into. My experience with ImageMagick is very
good, but if Python could do an equal good job, then it would be good
to switch. That also removes a dependency.


> 	Given that you do nothing between creating a subprocess and
> waiting for it to exit, subprocess.Popen() could be overkill -- the
> simpler subprocess.call() could be sufficient (heck, the old
> os.system() is sufficient, but preference seems to be to ignore it
> for subprocess.call() instead).

I already use check_call.


By the way: because of the lpr my script only works on Linux (and
probably Unix and Apple). Can I rewrite it in such a way that it also
works with Windows? Someone else has to test it then, because I do not
have a Windows computer.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91604

On Sun, 31 May 2015 19:06:40 +0200, Cecil Westerhof <Cecil@decebal.nl>
declaimed the following:

>
>By the way: because of the lpr my script only works on Linux (and
>probably Unix and Apple). Can I rewrite it in such a way that it also
>works with Windows? Someone else has to test it then, because I do not
>have a Windows computer.

	Not easily... Either you install something like cygwin which MAY
include LPR, or...

1)	You invoke (instead of LPR) some application that accepts a command
line argument telling it to do a print (I'm pretty sure that long ago M$
Word accepted a command line /p to print, but it seems that has gone away
replaced with something uglier -- notepad /p <file> works for simple text
files... I managed to get Acrobat Reader to open a PDF and bring up a print
requester, but that path still required the user to hit a number of dialog
windows)

2)	You incorporate win32 system calls to manage a print job in all details
(create bitmap, provide bitmap to print driver, etc.)

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#91645

Op Monday 1 Jun 2015 02:53 CEST schreef Dennis Lee Bieber:

> On Sun, 31 May 2015 19:06:40 +0200, Cecil Westerhof
> <Cecil@decebal.nl> declaimed the following:
>
>>
>> By the way: because of the lpr my script only works on Linux (and
>> probably Unix and Apple). Can I rewrite it in such a way that it
>> also works with Windows? Someone else has to test it then, because
>> I do not have a Windows computer.
>
> 	Not easily... Either you install something like cygwin which MAY
> include LPR, or...
>
> 1) You invoke (instead of LPR) some application that accepts a
> command line argument telling it to do a print (I'm pretty sure that
> long ago M$ Word accepted a command line /p to print, but it seems
> that has gone away replaced with something uglier -- notepad /p
> <file> works for simple text files... I managed to get Acrobat
> Reader to open a PDF and bring up a print requester, but that path
> still required the user to hit a number of dialog windows)
>
> 2) You incorporate win32 system calls to manage a print job in all
> details (create bitmap, provide bitmap to print driver, etc.)

Well, at the moment I will not bother about it then.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91627

On Sun, 31 May 2015 19:06:40 +0200, Cecil Westerhof <Cecil@decebal.nl> wrote:
>>
>>By the way: because of the lpr my script only works on Linux (and
>>probably Unix and Apple). Can I rewrite it in such a way that it also
>>works with Windows? Someone else has to test it then, because I do not
>>have a Windows computer.

You may find it easier to have the windows computers learn how to use
lpr.  see: http://www.morovia.com/kb/Setting-LPR-Printing-Windows-78-10007.html
(or there are lots of guides out there.)

Laura

[toc] | [prev] | [next] | [standalone]

#91621

Just for funsies, I did a slight rewrite using my scription[1] library:

--8<------------------------------------------------------------------------------
#!/usr/bin/python3
"""
Convert scanned images: contrast is increased, size is enlarged,
format is changed from jpeg to png.
"""

from __future__ import print_function   # only needed if running in 2
from glob import glob
from scription import *

@Command(
         threshold=Spec('cutoff value for white vs black', OPTION, type=int, default=66),
         verify=Spec('confirm conversion by viewing on screen', FLAG),
         )
def image_convert(verify, threshold):
     for count, input in enumerate(sorted(glob('*.JPG')), start=1):
         output = '{0:02d}.png'.format(count)
         # only prints if --verbose on commandline
         print('Going to convert {} to {}'.format(input, output))
         while True:
             # Execute automatically parses into a list
             attempt = Execute(
                     'convert -threshold {}% {} {}'.format(threshold, input, output),
                     interactive='echo',
                     )
             if attempt.returncode:
                 raise SystemExit(attempt.returncode)
             if not verify:
                 break
             attempt = Execute(
                     'display_the_png {}'.format(output),
                     interactive='echo',
                     )
             if attempt.returncode:
                 raise SystemExit(attempt.returncode)
             if get_response('Does the image look good?'):
                 break
             threshold = get_response("New threshold value:", type=int)
         # conversion looks good, or manual verification skipped
         print('going to print {0}'.format(output))
         attempt = Execute(
                 'lpr -o fit-to-page -o media=A4 {}'.format(output),
                 interactive='echo',
                 )
         if attempt.returncode:
             raise SystemExit(attempt.returncode)

Main()
--8<------------------------------------------------------------------------------

Opinions about the usability of the above script, both as the script writer and as the user, welcomed.

--
~Ethan~


[1] yes, everyone apparently writes their own command-line processor -- this one is mine.  ;)

[toc] | [prev] | [next] | [standalone]

#91630

On 05/31/2015 05:42 AM, Cecil Westerhof wrote:
> I help someone that has problems reading. For this I take photo's of
> text, use convert from ImageMagick to make a good contrast (original
> paper is grey) and use lpr to print it a little bigger.
>
I''m wondering why you bother to take a photo, which then has to be adjusted for quality.  A 
screen-capture program is much easier and immediately gives you a perfect(?) starting image.

Linux Mint that I use has the program 'gnome-screenshot' (in the main menu under Accessories as 
'Screenshot').  It gives you the options to capture the whole screen, the current active window, 
or any arbitrary rectangular area of the screen.  It saves it as a .png and allows you to 
specify the path/filename to save it.  I'm sure there are many other equivalent programs 
available as well, and this one or others are likely available by default in other Linux 
distros.  Or easily installed if not.

Of course, this just gives you the original 'raw' image that you can then process further as 
necessary.  But this is _FAR_ easier and better quality than the round-about method of using a 
camera.

      -=- Larry -=-

[toc] | [prev] | [next] | [standalone]

#91633

Larry Hudson writes:

> On 05/31/2015 05:42 AM, Cecil Westerhof wrote:
>> I help someone that has problems reading. For this I take photo's of
>> text, use convert from ImageMagick to make a good contrast (original
>> paper is grey) and use lpr to print it a little bigger.
>>
> I''m wondering why you bother to take a photo, which then has to be
> adjusted for quality.  A screen-capture program is much easier and
> immediately gives you a perfect(?) starting image.

"paper"

[toc] | [prev] | [next] | [standalone]

#91636

On Mon, 01 Jun 2015 11:06:33 +0300, Jussi Piitulainen wrote:

> Larry Hudson writes:
> 
>> On 05/31/2015 05:42 AM, Cecil Westerhof wrote:
>>> I help someone that has problems reading. For this I take photo's of
>>> text, use convert from ImageMagick to make a good contrast (original
>>> paper is grey) and use lpr to print it a little bigger.
>>>
>> I''m wondering why you bother to take a photo, which then has to be
>> adjusted for quality.  A screen-capture program is much easier and
>> immediately gives you a perfect(?) starting image.
> 
> "paper"

Have you looked at using OCR software combined with a scanner?
I have used tesseract in the past with very god results.


-- 
Eloquence is logic on fire.

[toc] | [prev] | [next] | [standalone]

#91655

Op Monday 1 Jun 2015 11:07 CEST schreef alister:

> On Mon, 01 Jun 2015 11:06:33 +0300, Jussi Piitulainen wrote:
>
>> Larry Hudson writes:
>>
>>> On 05/31/2015 05:42 AM, Cecil Westerhof wrote:
>>>> I help someone that has problems reading. For this I take photo's
>>>> of text, use convert from ImageMagick to make a good contrast
>>>> (original paper is grey) and use lpr to print it a little bigger.
>>>>
>>> I''m wondering why you bother to take a photo, which then has to
>>> be adjusted for quality. A screen-capture program is much easier
>>> and immediately gives you a perfect(?) starting image.
>>
>> "paper"
>
> Have you looked at using OCR software combined with a scanner?
> I have used tesseract in the past with very god results.

Does not work because it is not just straight text, there are headings
with text floating around it.

Also the funny thing is that I first scanned it. But it gave several
problems. One of them was that it is a format between A4 and A5.
Taking pictures is faster and gives better results.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91689

In a message of Mon, 01 Jun 2015 12:44:34 +0200, Cecil Westerhof writes:
>Also the funny thing is that I first scanned it. But it gave several
>problems. One of them was that it is a format between A4 and A5.
>Taking pictures is faster and gives better results.
>
>-- 
>Cecil Westerhof
>Senior Software Engineer
>LinkedIn: http://www.linkedin.com/in/cecilwesterhof

My irony detector may be on the fritz today, but, well, if you run into
some weird format between A4 and A5, you probably have a USA size.
see: http://en.wikipedia.org/wiki/Paper_size#North_American_paper_sizes

Most scanning programs have a way of specifying what paper size you want,
though those made in the USA have a natural tendancy to default to the
wierd American sizes.

Apologies if you already know all about this ...

Laura

[toc] | [prev] | [next] | [standalone]

#91696

Op Monday 1 Jun 2015 17:44 CEST schreef Laura Creighton:

> In a message of Mon, 01 Jun 2015 12:44:34 +0200, Cecil Westerhof
> writes:
>> Also the funny thing is that I first scanned it. But it gave
>> several problems. One of them was that it is a format between A4
>> and A5. Taking pictures is faster and gives better results.
>>
>> -- 
>> Cecil Westerhof
>> Senior Software Engineer
>> LinkedIn: http://www.linkedin.com/in/cecilwesterhof
>
> My irony detector may be on the fritz today, but, well, if you run
> into some weird format between A4 and A5, you probably have a USA
> size. see:
> http://en.wikipedia.org/wiki/Paper_size#North_American_paper_sizes

Nope, the dimensions are 177 mm x 227 mm.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91706

In a message of Mon, 01 Jun 2015 18:44:01 +0200, Cecil Westerhof writes:
>Op Monday 1 Jun 2015 17:44 CEST schreef Laura Creighton:
>
>> In a message of Mon, 01 Jun 2015 12:44:34 +0200, Cecil Westerhof
>> writes:
>>> Also the funny thing is that I first scanned it. But it gave
>>> several problems. One of them was that it is a format between A4
>>> and A5. Taking pictures is faster and gives better results.
>>>
>>> -- 
>>> Cecil Westerhof
>>> Senior Software Engineer
>>> LinkedIn: http://www.linkedin.com/in/cecilwesterhof
>>
>> My irony detector may be on the fritz today, but, well, if you run
>> into some weird format between A4 and A5, you probably have a USA
>> size. see:
>> http://en.wikipedia.org/wiki/Paper_size#North_American_paper_sizes
>
>Nope, the dimensions are 177 mm x 227 mm.
>
>-- 
>Cecil Westerhof
>Senior Software Engineer
>LinkedIn: http://www.linkedin.com/in/cecilwesterhof
>-- 
>https://mail.python.org/mailman/listinfo/python-list

Truly?  That's (very close to) 7 inch by 9 inch, 177.8 mm x 228.6 mm
and 7 by 9 is what pre-metric Britian called 'Small Post Quarto'.
I wonder if this merely a coincidence, or does some software really
still like this size?  How very weird.

Laura

[toc] | [prev] | [next] | [standalone]

#91711

Op Monday 1 Jun 2015 20:42 CEST schreef Laura Creighton:

> In a message of Mon, 01 Jun 2015 18:44:01 +0200, Cecil Westerhof
> writes:
>> Op Monday 1 Jun 2015 17:44 CEST schreef Laura Creighton:
>>
>>> In a message of Mon, 01 Jun 2015 12:44:34 +0200, Cecil Westerhof
>>> writes:
>>>> Also the funny thing is that I first scanned it. But it gave
>>>> several problems. One of them was that it is a format between A4
>>>> and A5. Taking pictures is faster and gives better results.
>>>>
>>>> -- 
>>>> Cecil Westerhof
>>>> Senior Software Engineer
>>>> LinkedIn: http://www.linkedin.com/in/cecilwesterhof
>>>
>>> My irony detector may be on the fritz today, but, well, if you run
>>> into some weird format between A4 and A5, you probably have a USA
>>> size. see:
>>> http://en.wikipedia.org/wiki/Paper_size#North_American_paper_sizes
>>
>> Nope, the dimensions are 177 mm x 227 mm.
>>
>> -- 
>> Cecil Westerhof
>> Senior Software Engineer
>> LinkedIn: http://www.linkedin.com/in/cecilwesterhof
>> -- 
>> https://mail.python.org/mailman/listinfo/python-list
>
> Truly?  That's (very close to) 7 inch by 9 inch, 177.8 mm x 228.6 mm
> and 7 by 9 is what pre-metric Britian called 'Small Post Quarto'.
> I wonder if this merely a coincidence, or does some software really
> still like this size?  How very weird.

Well, it is possible I did not measure correctly. ;-) It is a 32 page
booklet.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#91713

In a message of Mon, 01 Jun 2015 21:57:05 +0200, Cecil Westerhof writes:
>> Truly?  That's (very close to) 7 inch by 9 inch, 177.8 mm x 228.6 mm
>> and 7 by 9 is what pre-metric Britian called 'Small Post Quarto'.
>> I wonder if this merely a coincidence, or does some software really
>> still like this size?  How very weird.
>
>Well, it is possible I did not measure correctly. ;-) It is a 32 page
>booklet.
>
>-- 
>Cecil Westerhof
>Senior Software Engineer
>LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Ah, I have been misunderstanding the question.  It's the booklet itself
that is 7 by 9, not the rasters (or whatever) you get when you first
scan the thing.  Sorry about that.

Laura

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web