Created attachment 181500 [details] Various dropcaps, including hyphen Documentation does not state any limitation on drop caps.This means _any_ character at start of a paragraph can be accepted to create a drop cap. This works except when the characters selected by the setting are _all_ hyphens. In this case, Writer is completely confused: - for a single hyphen, the hyphen goes superscript with an excessive size and gets clipped off - for a sequence of hyphens, drop cap is one line high, no matter the number-of-lines setting in the paragraph style configuration. Trying to fix this erratic behaviour with a character style is not a viable solution. Anyway the glyph is excessively expanded (but this may be the result of the algorithm as is shown when using a period for the drop cap). The attached sample file demonstrates this weird hyphen handling. I admit that requesting drop cap when the first character is a hyphen doesn't make a lot of sense. However this bug report was inspired by discussion on https://ask.libreoffice.org/t/writer-punctuation-in-margins/76498 Similarly, if the first "character" is an image anchored "As character", the drop cap request is simply ignored. I accept it since the "standard" way of doing that is with a graphics frame and suitable wrap mode and position parameters. My request is to either fix the faulty hyphen behaviour or explicitly exclude hyphen with a mention in the documentation. Steps to reproduce: - configure some paragraph style for drop caps - create a paragraph with an initial hyphen (assuming relevant AutoCorrect options have been disabled) - style the paragraph for drop cap
(In reply to ajlittoz from comment #0) > My request is to either fix the faulty hyphen behaviour or explicitly > exclude hyphen with a mention in the documentation. > Agree. A symbol or punctuation being scaled upward to fit the specified height of the dropcap looks horrible--but is not incorrect. IMHO most reasonable would be to exclude use of certain glyphs, only using "literals" for each locale/script. Question would be how to organize that list. And, help/documentation would need a tweak.
(In reply to V Stuart Foote from comment #1) > A symbol or punctuation being scaled upward to fit the specified height of > the dropcap looks horrible--but is not incorrect. What is not incorrect? Looking horrible or using a punctuation. In any case, a hyphen should not be rendered superscript. There surely is a bug here. Unless contour detection is disturbed by some bad description of the glyph in the font. However, this superscript position occurs with different fonts. So it may be intrinsically related to the hyphen.
Such a black list is never complete and makes no one happy. I'd rather fix the faulty painting. Laszlo, Miklos: what's your take?
(In reply to Heiko Tietze from comment #3) > Such a black list is never complete and makes no one happy. Yes and considering the fact that Unicode may evolve (there are 16 planes: BMP is practically full; plane x01 is beginning to be heavily populated), you can't be exhaustive and the list is likely to be huge and thus unmanageable. That's why I'd accept "recommendations" in documentation. Then it would be user's responsibility to avoid pathological cases. However, if you fix hyphen (and potentially other glyphs), it's much better.
A simple workaround, which is back-compatible, too: insert a conditional hyphen before the first character of the paragraph by pressing Ctrl+- or using Insert->Formatting Mark->Insert soft Hyphen. @Ajlittoz: Thanks for the bug report! I agree with Heiko, it's hard to maintain such a list, and if this is not an interoperability issue, it's definitely better to avoid its modification. I suggest to check this (and the suggested workaround) in MSO to see the whole picture.
Created attachment 181624 [details] Hyphen not superscript I can see the gray field over the hyphen (menu View - Field Shadings). So for me is not in superscript. Note that field shading and/or dropcap size could change with zoom level. Actual results: It seems that the ghyph border "needs" to fill the height of the number of lines set for dropcap. That is why the hyphen or the period are shown so large. Expected results (warning: I am not a tech in typography, just sharing some ideas): I think that the glyph size must be proportional to an "X" height. The problem is largely unnoticeable because dropcaps usually are capital letters. Test with two characters, say "-x" and "-X". The hyphen must/could remain the same size in both cases. The same for ,."'* etc. It is a bit complicated. What about "p", "q", "g"? Why the descend (I don't remember the typographical jergon for what goes below the base line) do not goes below it? Ok, it will invade the fourth text row.
(In reply to László Németh from comment #5) > A simple workaround, which is back-compatible, too: insert a conditional > hyphen before the first character of the paragraph... ...removes the drop cap completely. IIUC the issue is about the hyphen / special character size. Anyway, no topic where UX can give valuable input.
Created attachment 181626 [details] sample document in MSO The size of the hyphen is correct in MSO.
(In reply to Heiko Tietze from comment #7) > (In reply to László Németh from comment #5) > > A simple workaround, which is back-compatible, too: insert a conditional > > hyphen before the first character of the paragraph... > > ...removes the drop cap completely. IIUC the issue is about the hyphen / > special character size. Anyway, no topic where UX can give valuable input. Ah, ok. Thanks. It seems, this is an interoperability issue, see the attached picture, so I'm going to check it.
(In reply to László Németh from comment #8) > Created attachment 181626 [details] > sample document in MSO > > The size of the hyphen is correct in MSO. I wouldn't say the hyphen is correctly positioned. If my mental model for drop cap is correct, only the glyph CONTOUR is taken into account, i.e. any metrics such as lateral or vertical space is stripped off (in fact ignoring any offset in the glyph description) leaving only the effectively used area in the glyph bounding rectangle. The contour is then scaled to fit the drop cap line requirement. In attachment 181626 [details], the hyphen top is aligned to the top line of the paragraph, with a lot of white space below, as if the space below was part of the contour. If you compare with the semicolon, the top of the top dot is aligned with first line top while the bottom of the bottom comma is aligned with third line bottom of the paragraph. In my mental model, hyphen should have been scaled so that the dash would be as high as the drop cap line requirement (3 lines), yes with an ugly result of an excessively large hyphen drop cap. See the full stop case for comparison where the dot occupies all three lines. So something is broken with the hyphen. Either it is drawn superscript as I suspect (to avoid excessive width?) or contour detection is faulty
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a18a74d6762e56a20093ca51cfd12925697c2524 tdf#150200 tdf#150438 sw, DOCX: fix drop cap dash, quotation etc. It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Commit message of the fix: tdf#150200 tdf#150438 sw, DOCX: fix drop cap dash, quotation etc. In drop cap layout, set smaller size for all glyphs positioned over the baseline, e.g. dashes (dash, en-dash, em-dash, figure dash), bullet, asterisks and quotation marks by extending the bounding box of the glyph to the baseline, like MSO does. Add "DropCapPunctuation", a new default compatibility option for this. Only old ODT files loads the old layout (which was partially broken: e.g. dashes were too long, often missing from the drop cap area or the drop cap was disabled). New ODT and imported DOCX documents use the new default layout for better typesetting and interoperability.
@Ajlittoz: thanks for reporting the problem! @All: Fortunately, there was a general solution for all similar drop cap interoperability problems (like Bug 150438). Thanks for your help!
The attached file won't be good but new ODT files work accurately like written in the Comment 12. Verified in: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: b323f1fba2a7a409177f5296c6ba8b98c9e537ad CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL