Created attachment 183252 [details] Example file that shows bad horizontal black lines Description: If you open the attachment, which is a DOC file, you will see bad Horizontal lines in Arabic/Persian text inside a text box. Steps to Reproduce: 1. Open the attachment Actual Results: Bad Horizontal lines (kashida) can be visible. The black lines should join the characters, and should not appear outside them. Expected Results: Kashida should be inserted in the correct position, Reproducible: Always User Profile Reset: Yes Additional Info: You may need "B Nazanin" font, but the problem should also be visible with other fonts. OK with LO 7.4: Version: 7.4.0.3 / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Reproducible with the latest LO 7.5 dev master: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fe1681b902caed0aaf9157ec31062d7627a1e1b9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded The file is downloaded from: https://ie.aut.ac.ir/files/ie/files/%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8_%D9%88%D8%A7%D8%AD%D8%AF.doc
Created attachment 183253 [details] PDF output from LO 7.5 dev master The output is not OK. There are kashidas which are placed incorrectly.
Created attachment 183254 [details] LibreOffice 5.0 In LO 5.0, gaps are visible, but no extra black lines Version: 5.0.0.1 Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e Locale: en-US (en_US.UTF-8)
Created attachment 183255 [details] LibreOffice 5.3 In LO 5.3, there are no gaps, but bad positioning of black horizontal lines is visible. Version: 5.3.0.1 Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9 CPU Threads: 8; OS Version: Linux 5.15; UI Render: default; VCL: x11; Layout Engine: new; Locale: en-US (en_US.UTF-8); Calc: group
I should add that I mistakenly written in comment 1 that it the output is OK with LO 7.4. Unfortunately it is not. The problem looks different in different zoom levels.
I can reproduce this bug can and confirm this.
There is this bug in LO 7.4.2.3 too.
(In reply to افشین from comment #5) > I can reproduce this bug can and confirm this. Please provide the build information from "Help > About LibreOffice".
(In reply to افشین from comment #5) > I can reproduce this bug can and confirm this. Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fa-IR (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.4.2~rc3-0ubuntu0.22.04.1~lo1 Calc: threaded
@Khaled: Could I have your opinion/view about this issue here please? This is one of the few issues around kashida which is still remaining.
I believe it is a limitation of the justification algorithm of Edit Engine; when there is an Arabic text it will always try to use kashida even when the space that is needed is less than the kashida width. Writer is smarter and will skip kashida and use spaces in such cases. Text boxes, even in Writer, use Edit Engine.
If some one is looking for code pointers, look for GetMinKashida() use under sw/, and try to locate the corresponding code under editeng/ and make it do something similar with GetMinKashida().
(In reply to خالد حسني from comment #11) > If some one is looking for code pointers, look for GetMinKashida() use under > sw/, and try to locate the corresponding code under editeng/ and make it do > something similar with GetMinKashida(). I am certainly interested in fix this issue. :-) It seems to be this part of the code: https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit3.cxx?r=f9395a12#2270 Commenting 10 lines from 2272 to 2281 out removes the kashida completely.
(In reply to Hossein from comment #12) > (In reply to خالد حسني from comment #11) > > If some one is looking for code pointers, look for GetMinKashida() use under > > sw/, and try to locate the corresponding code under editeng/ and make it do > > something similar with GetMinKashida(). > > I am certainly interested in fix this issue. :-) > > It seems to be this part of the code: > https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit3. > cxx?r=f9395a12#2270 > > Commenting 10 lines from 2272 to 2281 out removes the kashida completely. Yes. Now this code does not check if the adjustment being added against Kashida glyph width. I think the simpler adjustment is to check if nMore4Everyone >= MinKashidaWidth(), else drop all kashida positions. A smarter fix is to drop enough Kashida positions to make the condition is true. None of this is tested, so their might be extra complication, and it might be god idea to check what Writer does (I haven’t checked what it does exactly, to be honest) and do something similar for consistency.
I think the Kashida + RTL-Textbox bugs cover this, don't they?
Created attachment 195872 [details] A segment of the mis-rendered text, with LO 25.2 I want to try and better focus the description of the problem. I've attached a screenshot of part of the document (using a 25.2 nightly). Some letter-pairs have a bottom baseline which starts too early, so it begins before the "natural" connection of the two letter. Example: خط , the first word on the first line. The خ's stroke goes down and forward towards the baseline, but before it merges there's the horizontal stroke of something which looks like tatwil, starting. And it's not tatwil in the sense that there is no extension of the distance between the خ and the ط With other letter pairs, we see a middle-connect form of a letter when it should be just one-side connected. Example: نمايد, the first word on the second line. The letter ya, ي, the fourth letter, isn't connected to the alif just before it. But... we see a "tail" coming into the ya from the baseline, as though it were connected - as though we had a connecting letter instead of the alif, , e.g. ليد Build info: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 01e6e4303e5a9966f102e0357fe0354a2f74a1c4 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US
Created attachment 195873 [details] Reduced testcase of part of the problem This file only exhibits the first kind of problem I mentioned in my last comment. However - it does not require any part of the DOC file from the original testcase, nor the "Lotus" font which that document asks for. It uses DejaVu Sans, "Book" variant (which is the fallback font for Arabic glyphs on my system). Recreation instructions are: 1. New doc 2. Insert textbox 3. Set the paragraph direction to RTL 4. Type in خط تخوردگی و توسط 5. Select the typed text 6. Set the RTL-CTL font to DejaVu Sans Book 12 7. Set the textbox width so that only خط تخوردگی fits on the first line 8. "Play" with the textbox width, increasing and decreasing it, until you see the buggy tatwil "tail" between the two letters of the first word, خط (I also added a border line for the textbox which is not necessary)
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/937023bca427f803a9e7085d5090d5d2b17623ed tdf#151748 editeng: Improve kashida position validation It will be available in 25.2.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.
Thanks Jonathan, I verify the fix with 937023bca427f803a9e7085d5090d5d2b17623ed. But modifying the file a little, I got a crash. It seems to be related to the change as it happens in svx\source\svdraw\svdotextdecomposition.cxx:475. I see "span index out of range" when using []: for(sal_Int32 a=0; a < rInfo.mnTextLen; a++) { aKashidaArray.push_back(rInfo.mpKashidaArray[a]); } rInfo.mpKashidaArray is of size 32, and a is 32. rInfo.mnTextLen is 61. This font lacks Latin glyphs. The crash should be reproducible with these steps: 1. Open attahcment 183252 2. Edit page 2 main text box, select all, then set "B Lotus" font => Crash Backtrace from Visual Studio 2022: ucrtbased.dll!_invoke_watson(const wchar_t * expression, const wchar_t * function_name, const wchar_t * file_name, unsigned int line_number, unsigned __int64 reserved) Line 237 at minkernel\crts\ucrt\src\appcrt\misc\invalid_parameter.cpp(237) ucrtbased.dll!_invalid_parameter_internal(const wchar_t * expression, const wchar_t * function_name, const wchar_t * file_name, unsigned int line_number, unsigned __int64 reserved, __crt_cached_ptd_host & ptd) Line 114 at minkernel\crts\ucrt\src\appcrt\misc\invalid_parameter.cpp(114) ucrtbased.dll!_invalid_parameter(const wchar_t * expression, const wchar_t * function_name, const wchar_t * file_name, unsigned int line_number, unsigned __int64 reserved) Line 125 at minkernel\crts\ucrt\src\appcrt\misc\invalid_parameter.cpp(125) svxcorelo.dll!std::span<unsigned char const ,-1>::operator[](const unsigned __int64 _Off) Line 448 at C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\span(448) svxcorelo.dll!`anonymous namespace'::buildTextPortionPrimitive(const DrawPortionInfo & rInfo, const rtl::OUString & rText, const drawinglayer::attribute::FontAttribute & rFontAttribute, const std::vector<double,std::allocator<double>> & rDXArray, const basegfx::B2DHomMatrix & rNewTransform) Line 475 at svx\source\svdraw\svdotextdecomposition.cxx(475) svxcorelo.dll!`anonymous namespace'::impTextBreakupHandler::impCreateTextPortionPrimitive(const DrawPortionInfo & rInfo) Line 307 at svx\source\svdraw\svdotextdecomposition.cxx(307) svxcorelo.dll!`anonymous namespace'::impTextBreakupHandler::impHandleDrawPortionInfo(const DrawPortionInfo & rInfo) Line 672 at svx\source\svdraw\svdotextdecomposition.cxx(672) svxcorelo.dll!`anonymous namespace'::impTextBreakupHandler::decomposeBlockTextPrimitive(DrawPortionInfo * pInfo) Line 770 at svx\source\svdraw\svdotextdecomposition.cxx(770) svxcorelo.dll!`anonymous namespace'::impTextBreakupHandler::LinkStubdecomposeBlockTextPrimitive(void * instance, DrawPortionInfo * data) Line 728 at svx\source\svdraw\svdotextdecomposition.cxx(728) editenglo.dll!Link<DrawPortionInfo *,void>::Call(DrawPortionInfo * data) Line 111 at include\tools\link.hxx(111) editenglo.dll!Outliner::DrawingText(const Point & rStartPos, const rtl::OUString & rText, long nTextStart, long nTextLen, std::span<long const ,-1> pDXArray, std::span<unsigned char const ,-1> pKashidaArray, const SvxFont & rFont, long nPara, unsigned char nRightToLeft, const std::vector<EEngineData::WrongSpellClass,std::allocator<EEngineData::WrongSpellClass>> * pWrongSpellVector, const SvxFieldData * pFieldData, bool bEndOfLine, bool bEndOfParagraph, bool bEndOfBullet, const com::sun::star::lang::Locale * pLocale, const Color & rOverlineColor, const Color & rTextLineColor) Line 1665 at editeng\source\outliner\outliner.cxx(1665) editenglo.dll!OutlinerEditEng::DrawingText(const Point & rStartPos, const rtl::OUString & rText, long nTextStart, long nTextLen, std::span<long const ,-1> pDXArray, std::span<unsigned char const ,-1> pKashidaArray, const SvxFont & rFont, long nPara, unsigned char nRightToLeft, const std::vector<EEngineData::WrongSpellClass,std::allocator<EEngineData::WrongSpellClass>> * pWrongSpellVector, const SvxFieldData * pFieldData, bool bEndOfLine, bool bEndOfParagraph, const com::sun::star::lang::Locale * pLocale, const Color & rOverlineColor, const Color & rTextLineColor) Line 164 at editeng\source\outliner\outleeng.cxx(164) editenglo.dll!ImpEditEngine::Paint(OutputDevice & rOutDev, tools::Rectangle aClipRect, Point aStartPos, bool bStripOnly, o3tl::strong_int<short,FractionTag<10>> nOrientation) Line 3997 at editeng\source\editeng\impedit3.cxx(3997) editenglo.dll!EditEngine::StripPortions() Line 1083 at editeng\source\editeng\editeng.cxx(1083) editenglo.dll!Outliner::StripPortions() Line 1643 at editeng\source\outliner\outliner.cxx(1643) svxcorelo.dll!`anonymous namespace'::impTextBreakupHandler::decomposeBlockTextPrimitive(const basegfx::B2DHomMatrix & rNewTransformA, const basegfx::B2DHomMatrix & rNewTransformB, const basegfx::B2DRange & rClipRange) Line 139 at svx\source\svdraw\svdotextdecomposition.cxx(139) svxcorelo.dll!SdrTextObj::impDecomposeBlockTextPrimitiveDirect(drawinglayer::primitive2d::Primitive2DContainer & rTarget, SdrOutliner & rOutliner, const basegfx::B2DHomMatrix & rNewTransformA, const basegfx::B2DHomMatrix & rNewTransformB, const basegfx::B2DRange & rClipRange) Line 1893 at svx\source\svdraw\svdotextdecomposition.cxx(1893) svxcorelo.dll!`anonymous namespace'::TextEditOverlayObject::checkDataChange(const basegfx::B2DRange & rMinTextEditArea) Line 786 at svx\source\svdraw\svdedxv.cxx(786) svxcorelo.dll!SdrObjEditView::EditViewInvalidate(const tools::Rectangle & __formal) Line 861 at svx\source\svdraw\svdedxv.cxx(861) editenglo.dll!ImpEditView::InvalidateAtWindow(const tools::Rectangle & rRect) Line 890 at editeng\source\editeng\impedit.cxx(890) editenglo.dll!ImpEditView::ResetOutputArea(const tools::Rectangle & rRect) Line 951 at editeng\source\editeng\impedit.cxx(951) editenglo.dll!ImpEditView::RecalcOutputArea() Line 1026 at editeng\source\editeng\impedit.cxx(1026) editenglo.dll!ImpEditEngine::CheckAutoPageSize() Line 630 at editeng\source\editeng\impedit3.cxx(630) editenglo.dll!ImpEditEngine::FormatDoc() Line 546 at editeng\source\editeng\impedit3.cxx(546) editenglo.dll!ImpEditEngine::FormatAndLayout(EditView * pCurView, bool bCalledFromUndo) Line 4767 at editeng\source\editeng\impedit3.cxx(4767) editenglo.dll!ImpEditEngine::SetUpdateLayout(bool bUp, EditView * pCurView, bool bForceUpdate) Line 4438 at editeng\source\editeng\impedit3.cxx(4438) editenglo.dll!EditView::SetEditEngineUpdateLayout(bool bUpdate) Line 808 at editeng\source\editeng\editview.cxx(808) editenglo.dll!OutlinerView::SetAttribs(const SfxItemSet & rAttrs) Line 437 at editeng\source\outliner\outlvw.cxx(437) svxcorelo.dll!SdrObjEditView::SetAttributes(const SfxItemSet & rSet, bool bReplaceAll) Line 2530 at svx\source\svdraw\svdedxv.cxx(2530) svxcorelo.dll!SdrCreateView::SetAttributes(const SfxItemSet & rSet, bool bReplaceAll) Line 878 at svx\source\svdraw\svdcrtv.cxx(878) svxcorelo.dll!SdrView::SetAttributes(const SfxItemSet & rSet, bool bReplaceAll) Line 188 at include\svx\svdview.hxx(188) swlo.dll!SwDrawTextShell::SetAttrToMarked(const SfxItemSet & rAttr) Line 165 at sw\source\uibase\shells\drwtxtsh.cxx(165) swlo.dll!SwDrawTextShell::ExecutePost(SfxRequest & rReq, unsigned short nEEWhich, SfxItemSet & rNewAttr, OutlinerView * pOLV, bool bRestoreSelection, const ESelection & rOldSelection) Line 638 at sw\source\uibase\shells\drwtxtex.cxx(638) swlo.dll!SwDrawTextShell::Execute(SfxRequest & rReq) Line 611 at sw\source\uibase\shells\drwtxtex.cxx(611) swlo.dll!SfxStubSwDrawTextShellExecute(SfxShell * pShell, SfxRequest & rReq) Line 10494 at workdir\SdiTarget\sw\sdi\swslots.hxx(10494) sfxlo.dll!SfxDispatcher::Call_Impl(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, bool bRecord) Line 254 at sfx2\source\control\dispatch.cxx(254) sfxlo.dll!SfxDispatcher::Execute_(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, SfxCallMode eCallMode) Line 753 at sfx2\source\control\dispatch.cxx(753) sfxlo.dll!SfxDispatcher::Execute(unsigned short nSlot, SfxCallMode nCall, const SfxItemSet * pArgs, const SfxItemSet * pInternalArgs, unsigned short nModi) Line 813 at sfx2\source\control\dispatch.cxx(813) sfxlo.dll!SfxDispatchController_Impl::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgs, const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> & rListener) Line 675 at sfx2\source\control\unoctitm.cxx(675) sfxlo.dll!SfxOfficeDispatch::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgs) Line 254 at sfx2\source\control\unoctitm.cxx(254) sfxlo.dll!SfxToolBoxControl::Dispatch(const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchProvider> & rProvider, const rtl::OUString & rCommand, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aArgs) Line 253 at sfx2\source\toolbox\tbxitem.cxx(253) svxcorelo.dll!`anonymous namespace'::SvxFontNameBox_Base::Select(bool bNonTravelSelect) Line 2007 at svx\source\tbxctrls\tbcontrl.cxx(2007) svxcorelo.dll!`anonymous namespace'::SvxFontNameBox_Base::ActivateHdl(weld::ComboBox & __formal) Line 1968 at svx\source\tbxctrls\tbcontrl.cxx(1968) svxcorelo.dll!`anonymous namespace'::SvxFontNameBox_Base::LinkStubActivateHdl(void * instance, weld::ComboBox & data) Line 1965 at svx\source\tbxctrls\tbcontrl.cxx(1965) vcllo.dll!Link<weld::ComboBox &,bool>::Call(weld::ComboBox & data) Line 111 at include\tools\link.hxx(111) vcllo.dll!SalInstanceComboBoxWithEdit::EntryActivateHdl(Edit & __formal) Line 6812 at vcl\source\app\salvtables.cxx(6812) vcllo.dll!SalInstanceComboBoxWithEdit::LinkStubEntryActivateHdl(void * instance, Edit & data) Line 6809 at vcl\source\app\salvtables.cxx(6809) vcllo.dll!Link<Edit &,bool>::Call(Edit & data) Line 111 at include\tools\link.hxx(111) vcllo.dll!Edit::ImplHandleKeyEvent(const KeyEvent & rKEvt) Line 1672 at vcl\source\control\edit.cxx(1672) vcllo.dll!Edit::KeyInput(const KeyEvent & rKEvt) Line 1704 at vcl\source\control\edit.cxx(1704) vcllo.dll!ImplHandleKey(vcl::Window * pWindow, NotifyEventType nSVEvent, unsigned short nKeyCode, unsigned short nCharCode, unsigned short nRepeat, bool bForward) Line 1211 at vcl\source\window\winproc.cxx(1211) vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalEvent nEvent, const void * pEvent) Line 2724 at vcl\source\window\winproc.cxx(2724) vcllo.dll!SalFrame::CallCallback(SalEvent nEvent, const void * pEvent) Line 312 at vcl\inc\salframe.hxx(312) vclplug_winlo.dll!ImplHandleKeyMsg(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam, __int64 & rResult) Line 3960 at vcl\win\window\salframe.cxx(3960) vclplug_winlo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam, bool & rDef) Line 6036 at vcl\win\window\salframe.cxx(6036) vclplug_winlo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 6356 at vcl\win\window\salframe.cxx(6356) user32.dll!UserCallWinProcCheckWow() user32.dll!CallWindowProcW() opengl32.dll!wglWndProc() user32.dll!UserCallWinProcCheckWow() user32.dll!DispatchMessageWorker() vclplug_winlo.dll!ImplSalDispatchMessage(const tagMSG * pMsg) Line 475 at vcl\win\app\salinst.cxx(475) vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 544 at vcl\win\app\salinst.cxx(544) vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 581 at vcl\win\app\salinst.cxx(581) vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 385 at vcl\source\app\svapp.cxx(385) vcllo.dll!Application::Yield() Line 473 at vcl\source\app\svapp.cxx(473) vcllo.dll!Application::Execute() Line 361 at vcl\source\app\svapp.cxx(361) sofficeapp.dll!desktop::Desktop::Main(void) vcllo.dll!ImplSVMain() Line 228 at vcl\source\app\svmain.cxx(228) vcllo.dll!SVMain() Line 261 at vcl\source\app\svmain.cxx(261) sofficeapp.dll!soffice_main() soffice.bin!sal_main() Line 51 at desktop\source\app\main.c(51) soffice.bin!main(int argc, char * * argv) Line 49 at desktop\source\app\main.c(49) soffice.bin!invoke_main() Line 79 at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79) soffice.bin!__scrt_common_main_seh() Line 288 at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288) soffice.bin!__scrt_common_main() Line 331 at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331) soffice.bin!mainCRTStartup(void * __formal) Line 17 at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17) kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart()
To clarify, the above crash-assert does not happen with one commit before, which is 937023bca427f803a9e7085d5090d5d2b17623ed~1: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6475adeb03962c6c1aa1696e4b96928b9a3286ef CPU threads: 20; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Reopening this bug for crash investigation.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/9d45184354c9f4b6475fa845bea8cc425babed49 tdf#151748 editeng: Improve kashida position validation It will be available in 24.8.2. 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.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7ff601feca1796b6656e66c7ce2e77edcf0bdd67 tdf#151748 editeng: Fix crash in kashida justification after update It will be available in 25.2.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.
Thanks Jonathan, The crash went away with your latest patch. But unfortunately, there is still a temporary issue with bad horizontal lines. You can reproduce the problem with these steps: 1. Open attahcment 183252 2. Edit page 2 main text box, select all, then set "B Nazanin" font You will see bad horizontal lines while in edit mode. If you click outside the text box, the problem goes away.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/ac40f72c97703979994ac9d54ce861269653950e tdf#151748 editeng: Fix crash in kashida justification after update It will be available in 24.8.2. 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.
(In reply to Hossein from comment #23) > Thanks Jonathan, > The crash went away with your latest patch. > > But unfortunately, there is still a temporary issue with bad horizontal > lines. > > You can reproduce the problem with these steps: > > 1. Open attahcment 183252 > 2. Edit page 2 main text box, select all, then set "B Nazanin" font > > You will see bad horizontal lines while in edit mode. If you click outside > the text box, the problem goes away. I was able to reproduce this issue in 22.4. Editeng is failing to clear kashida positions when e.g. a font change reduces the number of lines in a paragraph, and the last line is no longer justified. This bug tracks drawing kashida where there isn't enough space. Since this issue isn't directly related to this one, and can be reproduced without this code change, I would prefer to handle it as part of a separate bug.