Recent posts

#1
Beginner Talk / Re: Why use DPI (not ppi)? (im...
Last post by Aleks100 - June 23, 2024, 06:30:44 PM
For practical reasons IMHO in printing it is better to look at LPI value as analogue to PPI on screen.
Nice & short explanation is here:
https://apmbags.com/what-difference-between-dpi-ppi-and-lpi
#2
PDF Generation / Re: Inconsistent PDF output fo...
Last post by Nermander - June 23, 2024, 05:10:16 PM
Quote from: eeedelli on June 23, 2024, 03:22:01 PMAlso - how is it possible that other programs that also output to pdf for print purposes manage to do it in such a way that the 'read out loud' option in Adobe Acrobat still works?  If they can do it, it does demonstrate that such things must be possible!

The put the text in PDF "stories" (I think it's called).

Essentially, they place the cursor and then output a full line of text.

Scribus on the other hand may place the glyphs individually. It places the cursor, places one glyph, then places the cursor again, places next glyph. This gives a lot higher precision when placing the glyphs, which is good for print. For print it does not even matter in which order the glyphs are placed, becuase you just see the end result, not how it was "built". Essentially Scribus could first place all a:s, then all b:s etc. You would not see any difference in the end result when printed.
#3
PDF Generation / Re: Inconsistent PDF output fo...
Last post by eeedelli - June 23, 2024, 03:22:01 PM
Quote from: eeedelli on June 23, 2024, 02:08:00 PMIf not, it reduces the usefulness of Scribus in comparison with other products which produce output not only for print but also for devices.

Also - how is it possible that other programs that also output to pdf for print purposes manage to do it in such a way that the 'read out loud' option in Adobe Acrobat still works?  If they can do it, it does demonstrate that such things must be possible!

The other point here is that this seems to be a completely random problem - some of the identical sentences in two slightly different versions created from the same original file (as demonstrated in the example files) produce totally different results. That does rather suggest that this is unintentional (or, at least, not specifically considered), which also suggests that something rather odd is happening.  Surely computing output should be consistent and should never produce random results? That would seem very strange.
#4
PDF Generation / Re: Inconsistent PDF output fo...
Last post by eeedelli - June 23, 2024, 02:08:00 PM
Quote from: Nermander on June 23, 2024, 01:28:11 PMScribus was mainly designed for producing PDFs for print, this means Scribus does not write "sentences" or even "words" in the PDF, it often places individual glyphs. And that of course makes if very difficult for a program to figure out in what order to read things.

True.  Fair point. 

Mind you, these days, it is becoming commonplace for files originally intended for print to be used on (and read aloud by) electronic devices, as a matter of course, let alone for those who might have a disability and really do need that option, who we should not be excluding.

I wonder whether it's something that is possible to fix?  If not, it reduces the usefulness of Scribus in comparison with other products which produce output not only for print but also for devices.
#5
Beginner Talk / Re: Why use DPI (not ppi)? (im...
Last post by Nermander - June 23, 2024, 01:29:16 PM
Quote from: RodneyLee on June 21, 2024, 02:54:33 PMA DOT is a PIXEL

No, for most printing techniques a pixel is rasterized into many smaller dots.

For example most 2400 DPI inket printers print 300 PPI, each pixel is represented by 4x4 dots.
#6
PDF Generation / Re: Inconsistent PDF output fo...
Last post by Nermander - June 23, 2024, 01:28:11 PM
Scribus was mainly designed for producing PDFs for print, this means Scribus does not write "sentences" or even "words" in the PDF, it often places individual glyphs. And that of course makes if very difficult for a program to figure out in what order to read things.
#7
PDF Generation / Inconsistent PDF output for Ad...
Last post by eeedelli - June 23, 2024, 01:02:16 PM
Hello everyone.

I've been using Scribus for a while now to create the quarterly magazine for our model railway club. We have a couple of members who are dyslexic, so reading lots of text is difficult for them and one, in particular, relies on his phone/PC to read things out loud as his dyslexia is quite severe. I've been attempting to generate the pdf output in a way that will work for him.

I was previously using Scribus 1.4.8 but found it wasn't creating selectable text in the pdf output. I then found lots of threads about un-ticking the subset box in the font settings and uprating the pdf output to v1.6.

I have now done those (and upgraded to Scribus 1.6.2. (on Win 10) while I was at it.)

Although I can now wipe over and select text in the pdf output, I'm finding that using the Adobe 'read out loud' feature (Files > View > Read Out Loud in Acrobat) is producing very strange results.

Some text reads fine. Other text has massive pauses between words and the effect seems to be completely random. This mirrors what can be seen when you click on the text when in the 'read out loud' mode in Acrobat.

The areas that read correctly are all grouped together in a box. Other lines, however, have no grouping at all and the cursor either lands with no boxing around it or the boxing is a part of a word, or a small group of words. (e.g. the word 'caption' is boxed up as 'captio' then a second box for 'n')

This results in the reader voicing up the words separately, with approx. 1 second silences between them (making it unusable), while the words that are grouped together as part of a sentence sometimes all tumble out sounding as though the spaces between the words are not there, resulting in many mispronunciations in rapid fire, making it largely incomprehensible (though it didn't do that in the examples here).

This seems to be a completely random issue. I have uploaded the .sla file and two slightly different versions of the .pdf output to a dropbox folder here: Example files

As you will see if you download the pdf files, the first one I tried (called 'test') produces audio output for the first couple of lines correctly, fails to read the caption correctly, then reads the final sentence below the photo in three chunks.

The slightly later version (with the longer final sentence - and full file name) fails to read any of it at a sensible speed at all.

It seems that Scribus isn't creating consistent grouping of words and sentences for the pdf output. It doesn't seem to make any difference whether one uses file > export > save as pdf, or file > print to pdf.

Does anyone have a solution to this problem, please?

#8
Beginner Talk / Re: Why use DPI (not ppi)? (im...
Last post by Yichuang驿窗 - June 22, 2024, 12:57:00 AM
A Dot is a Pixel, maybe YES, maybe NO.

Example for YES:
----------------------

An image file is 600x300 px,resolution is 300 PPI,it was printed on a paper with a laser printer, the accuracy of the laster printer is 300 DPI.


The printout result is,an image on paper that is 2 inches in horizontal dimension and that 2 inches consists of 600 pixels. The image is 1 inch in portrait dimension and the 1 inch consists of 300 pixels.

"2 inches in horizontal dimension" is because of 600px÷300PPI, "1 inches in portrait dimension" is because of 300px÷300PPI.

Because the printer's accuracy is 300 DPI, the printer will print 300 Dots on a one-inch length of paper. Corresponding to the image printed above, the image is 2x1 inches, so 600 Dots are printed horizontally(2 inches x 300 DPI); 300 Dots are printed vertically(1 inch x 300 DPI).

Summary:
An image on paper has 600 Pixels in the horizontal direction, and these 600 Pixels are rendered by the printer with 600 toner Dots; in the vertical direction, there are 300 Pixels, and these 300 Pixels are rendered by the printer with 300 toner Dots.

Here, the pixels and toner dots correspond to each other, and the result is what we call "A dot is a pixel".



Example for NO:
----------------------

Same image file, same laser printer. Before printing, we change the resolution of the image from 300 PPI to 600 PPI, then print the image to paper and see what changes.

(Note that the image file is now 600x300 pixels, the resolution is 600 PPI, and the printer precision is 300 DPI).

Since the image has a resolution of 600 PPI, the image printed to paper is 1 inch (600px÷600PPI) horizontally and 0.5 inches (300px÷600PPI) vertically.

While on paper, the printer still uses 300 toner dots to render an inch long image content, that is, 1x0.5-inch image, horizontal 1 inch, there are 300 toner dots; vertical 0.5 inches, there are 150 toner dots.

The result is that printing a 1x0.5-inch image on paper with 600 pixels an inch horizontally requires only 300 toner dots; printing a 0.5-inch image with 300 pixels vertically requires only 150 toner dots.

Summary:

An image on paper has 600 pixels in landscape, which are rendered by the printer with 300 toner dots, and 300 pixels in portrait, which are rendered by the printer with 150 toner dots.

Here, the pixels and toner dots are not one-to-one and become "One dot is (rendered with) Two pixel".


======================
In the above examples, if the precision of the printer changes(300DPI to 600DPI, or 300DPI to 150DPI), it will likewise affect the toner_dot-to-pixel correspondence.

So, exactly how the dots correspond to the pixels is mainly affected by two elements, one is the resolution PPI of the image and the other is the precision DPI of the printer.

However, the only element that determines the size of an image on paper is the PPI, not the DPI.
#9
PDF Generation / Re: Best pdf output for Family...
Last post by FemmesoleNZ - June 22, 2024, 12:17:57 AM
I have just tried this out; see results in image. Was much easier. The lower part is using the vector method you described and this seems to have changed the output such that the font now appears 'cramped' and much harder to read in my opinion, while the upper part is from importing the png. I think the vector method would be better, but I would have to experiment with fonts to find an appropriate one for the original file. I know it is not usual, but I found that the best font for getting a great deal of information on a page was Arial Narrow, so I have used only Arial Narrow and Arial Narrow Bold in the reports from Legacy, and thus elsewhere I have used text. The text is generally size 12; so reduces slightly when imported into the image frame in Scribus.

As I am halfway into the second book of a two part set, I am not going to change the method now, but I really appreciate your giving me this assistance and certainly something to experiment with. Thank you very much.

#10
Features / Re: Make gradients easier to m...
Last post by tim_occ - June 21, 2024, 11:37:54 PM
This is how it looks like in Scribus 1.7.0 svn.