When inserting an inline note in a PDF file the size of the rectangular background area seems to be determined solely by number of characters, not taking into account the font size, and the boundaries of that rectangle do not respect the boundaries drawn by the user when inserting the note. This makes it very hard to use the space available in a text document to write inline notes as, even shrinking font size, it will most often just overlap with document's content. I am also not able to constrain the area where the note will show up as okular seems to only partially obey the rectangle the user draws by clicking and dragging when inserting the note. Reproducible: Always Steps to Reproduce: 1. Adjust annotation settings and decrease font size for the inline notes to say, Ubuntu 8. Change positioning of text to Centered (optional) 2. Click on the inline annotation button (may be necessary to first bring the Review Panel by pressing F6) 3. Click and drag to draw a rectangular area where the desired note should be. 4. Write a somewhat long piece of text (about 2 full sentences). Actual Results: Observe how disproportional the rectangular area is to the text, wasting a lot of space and covering other parts of the document, and how it does not respect the area drawn by the user in step 3. Expected Results: The rectangular area drawn by the user should be respected and/or the rectangle shape should fit the text and be calculated based on font size and area drawn by the user.
Created attachment 82422 [details] Example of the described problem
Hey I would like refresh this bugreport. The text in inline annotation should set framer border at least. Or frame should has variable size.
Confirmed on Okular 0.19.60 (In reply to comment #0) > Expected Results: > The rectangular area drawn by the user should be respected and/or the > rectangle shape should fit the text and be calculated based on font size and > area drawn by the user. So, for sure the boundary box should be more "fit" with the real text (with no blank areas around as it happens right now), but what do you expect it would make more sense when the text? Let the shape to be fixed, so truncate the text which does not fit (respecting the choice of the font), or increase the shape anyway (provided that the area fits the text perfectly and that can be resized)?
Similar problem here, except that text is cut off instead of too much space shown. I would expect the following: 1) Try to fit the boundary box to the text - dont use more or less space 2) Let user resize the boundary box, e. g. by pushing Shift+Ctrl and the left mouse (similar to moving it)
Created attachment 89076 [details] Animated gif which shows the original input and the boundary box afterwards I quickly created an animated gif which shows the original input and the boundary box afterwards. Hope this helps!
Any progress?
With Okular 1.1 this bug seems partially solved because: - if the inline note rectangle is too small, it is resized in order to fit all the text without hiding it - The inline note is now resizable Still not solved: - Too much white space added in the rectangle under the text Regarding the inline note rectangle behavior. In my opinion, the default behavior of an inline note should be to resize the rectangle in order to show all the text and allow the user to resize it down, possibly hiding some text, in as second moment (as it is now). If one has to write a lot of text the logical correct tool seems the popup note.
At least one cause for the misfit is this: Okular doesn't consult generator/poppler for required size when it calculates the desired bounding box of annotations. Actually it can't, because Poppler has no such API yet. Instead Okular tries to guess the size of the bounding box on its own by using QFontMetricsF::boundingRect [0]. Only the annotation rendering engine (i.e. Poppler) could know the exact size. E.g. it's not even guaranteed that QFontMetricsF and Poppler actually select the same font (may or may not use lib fontconfig to search fonts, afaikt) even if description matches. A QT-based guess can always be more or less wrong. [0] https://cgit.kde.org/okular.git/tree/ui/pageviewannotator.cpp?h=Applications/18.04#n199
There is also a Poppler bug concerning fonts in annotations which might be related to the present matter: https://bugs.freedesktop.org/show_bug.cgi?id=65956#c14 <quote> Apparently the font configured to be used in the annotation is ignored in general. Maybe this should be fixed and the rest might work then? </quote> Another point is I agree with comment saying that the shape and size of the bounding box cannot be reasonably be fixed in advance ("drawn boundaries") <https://bugs.kde.org/show_bug.cgi?id=325119#c3>. I think it should be marked as duplicate of the above Poppler bug; and as for the "drawn boundaries", a wishlist bug should be opened where the intended behavior of the "drawn box" could be discussed. Also, since applications 17.08, it is very easy to reshape the box after the text is entered.
(In reply to Chris from comment #9) > There is also a Poppler bug concerning fonts in annotations which might be > related to the present matter: > https://bugs.freedesktop.org/show_bug.cgi?id=65956#c14 > <quote> > Apparently the font configured to be used in the annotation is ignored in > general. Maybe this should be fixed and the rest might work then? > </quote> There's one more dedicated poppler bug "FreeText annotation ignores font": https://bugs.freedesktop.org/show_bug.cgi?id=81748 Hopefully we can fix it during GSoC 18, or in some follow up patches. > Another point is I agree with comment saying that the shape and size of the > bounding box cannot be reasonably be fixed in advance ("drawn boundaries") > <https://bugs.kde.org/show_bug.cgi?id=325119#c3>. Would you agree with Simone in comment 7? > default behavior of an inline note should be to resize the rectangle > in order to show all the text and allow the user to resize it down Because that's what we try atm, even for a "drawn boundary". It just doesn't work 100% perfect because of more subtle problems (font ignored, different rendering engines at work). > I think it should be marked as duplicate of the above Poppler bug; and as > for the "drawn boundaries", a wishlist bug should be opened where the > intended behavior of the "drawn box" could be discussed. Poppler is hosted by freedesktop, Okular is hosted by KDE. We can't mark duplicates between different projects on different hosts, can we? But giving a link in each place is always good. > Also, since applications 17.08, it is very easy to reshape the box after the > text is entered. Glad if it's useful:)
This is still an issue. The text box around Inline note elements still seems to have very big right and bottom margins in Okular. But when text elements (both Inline note and Typewriter annotations) created in Okular are opened in another PDF reader, such as Acrobat reader or pdf.online web-app, then the text element containing box actually becomes too small instead: The font face, size and color are substituted with another (standard/default) font face/size/color in other PDF readers. This font face requires more space compared to the font face used in Okular, but text element containing boxes does not get bigger and as a result text from Okular is cropped. Unless the font size for annotations is set to 12 (in contrast to default 9) in Okular this cropping happens frequently for text elements with several words or several lines of text. With this issue in mind it might actually be more important (to guarantee basic functionality) to increase the padding around text elements, rather than making the padding smaller (with better looks in mind).