/linguistic/

Age	Commit message (Collapse)	Author
2023-11-25	tdf#158317 fix cleanup of SfxPoolItems in editeng	Armin Le Grand (allotropia)
	It is not possible to use implCreateItemEntry/implCleanupItemEntry, that is tooling limited by purpose to svl/Item/ItemSet stuff. But what I can do is to do that SfxPoolItemHolder I already talked/thought about. It is a helper that can safely hold a SfxPoolItem in cases where an SfxItemSet is too expensive. Think about it as a SfxItemSet for a single item. That solves the problem why DirectPutItemInPool/DirectRemoveItemFromPool is used in general (each usage is a 'compromize'). Did that now, works well. Editengine is now free of DirectPutItemInPool/DirectRemoveItemFromPool. Replaced ::CursorMoved with checkAndDeleteEmptyAttribs since all these got static with no longer need to DirectRemoveItemFromPool. Corrected create/delete counters. Change-Id: Ia6e53f48ac2e479b461546515e68697039b5b628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159931 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-08-18	ITEM: preparations for more/easier changes	Armin Le Grand (allotropia)
	This change is not about speed improvements but diverse preparations to make changes/reading/understanding easier. It does not change speed AFAIK. Added a global static debug-only counter to allow getting an overview over number of all allocated SfxPoolItem's and the still alloated ones at office shutdown. The values are used in Application::~Application to make a short info statement. It allows to be able to quickly detect if an error in future changes may lead to memory losses - these would show in dramaitically higher numbers then (hopefully) immediately. Moved SfxVoidItem to own source/header. Added container library interface support to SfxItemSet, adapted already some methods to use it - not all possible, I will commit & get status from gerrit 1st if all still works and then continue. Changed INVALID_POOL_ITEM from -1 to use a global unique incarnation of an isolated derivation from SfxPoolItem. It allows to avoid the (-1) pointer hack. Since still just pointers are compared it's not worse. NOTE: That way, more 'special' SfxPoolItem's may be used for more States - a candidate is e.g. SfxVoidItem(0) which represents ::DISABLED state -- unfortunately not only, it is also used (mainly for UI stuff) with 'real' WhichIDs - hard to sort out, will have to stay that way for now AFAIK. Changed INVALID_POOL_ITEM stuff to use a static extern incarnated item in combination with a inline method to return it, called GetGlobalStaticInvalidItemInstance(). Isolated create/cleanup of a SfxPoolItem entry in SfxItemSet to further modularize/simplify that. It is currently from constructor & destructor but already shows that PoolDefaults are handled differently - probably an error. Still, for now, do no change in behaviour (yet). Got regular 'killed by the Kill-Wrapper' messages from gerrit, seems to have to do with UITest_sw_findReplace. That python/c++ scripting stuff is hard to debug, but finally I identified the problem has to do with the INVALID_POOL_ITEM change. It was in SfxItemSet::InvalidateAllItems() where still a (-1) was used -> chaos in detecting invalid items. Change-Id: I595e1f25ab660c35c4f2d19c233d1dfadfe25214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155675 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-07-06	tdf#126382 Correct check for transparency	Maxim Monastirsky
	Change-Id: I0664abae6f83736678108fab31dd119fae811054 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154082 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2023-06-15	tdf#103064 editeng: fix handling of char highlighting	Maxim Monastirsky
	Transparency should be set to false if a color is present, but not with COL_TRANSPARENT. Compare with what is done for shape text in VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D. Change-Id: I5e4c8e53b53a363813ced50358c5ee795cdb61dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153107 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2023-04-04	tdf#153880 sc: Make Calc text hyperlinks stand out more	Balazs Varga
	Add underlining for links in Calc. TODO: unit test Change-Id: Idd5a7de7464d8ce443cdec756ac803491e73b0ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149913 Tested-by: Jenkins Tested-by: Gabor Kelemen <kelemeng@ubuntu.com> Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2021-05-31	Clean redundant SvxBackgroundColorItem and use SvxColorItem instead.	Gülşah Köse
	SvxBackgroundColorItem is just copied from SvxColorItem. There is nothing special to SvxBackgroundColorItem class. SvxColorItem is a generic item and it's used on many places related with colors. We can use SvxColorItem for background colors too. Change-Id: Iacea31a7557b806e95f5859ff60add9a2626ec05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116282 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jenkins
2021-03-19	silence coverity unchecked return value from library on xmlText* functions	Caolán McNamara
	Change-Id: I651abb00d8ae1bdbf758a6a0176fd8912531a585 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112753 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-03	tdf#80194 autoEsc: use fontmetrics in calculation	Justin Luth
	This replaces the previous 7.0 patch in commit 2940d1905b921d9909b08b1e32014d3c44474ef0 where the following is still true: THIS WILL CHANGE THE POSITION OF EDITENG SUBSCRIPTS AND SUPERSCRIPTS IN EXISTING DOCUMENTS! That is because they were very poorly placed before - using a formula that is very different from how Writer does it. Everyone in the bug reports indicates that Writer does it good, but Impress does it really bad. (tdf#89849, tdf#63083). Instead of using the previous patch's 80%/20% generalization, copy Writer's use of the actual ascent and descent of the font to determine the best position for the subscript or superscript. Change-Id: I0f10f6174b0709f3bc3b9acdc54b7b1fd59c5ee2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90489 Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Justin Luth <justin_luth@sil.org>
2020-03-03	tdf#80194 editeng: fix auto subscript calculations	Justin Luth
	...and auto superscript too (although not as noticably). THIS WILL CHANGE THE POSITION OF EDITENG SUBSCRIPTS AND SUPERSCRIPTS IN EXISTING DOCUMENTS! That is because they were very poorly placed before - using a formula that is very different from how Writer does it. Everyone in the bug reports indicates that Writer does it good, but Impress does it really bad. (tdf#89849, tdf#63083) FOR EXAMPLE, when the char-size is reduced to the default OF 58%, it will now be raised by 33%, not 42%. Likewise, the subscript will now be lowered by 8%, not 42%. THIS AFFECTS/FIXES Writer textboxes, Calc, Draw/Impress. "Automatic" indicates that there is not a "correct" answer, but that the computer should make it "look good", so the user should be able to accept this change in positioning, as long as it looks good. The number of documents affected might be less than one would expect. By default .uno:SuperScript does NOT set auto mode (although Format-Character does). Since most people would use the toolbar instead of the format menu to create a superscript, auto will be rare. So there will be relatively few cases where subscripts are automatic in editeng, especially since it looks so poor that most people probably turned automatic off... This patch has no effect on non-automatic escapement. It uses the same fomula that calculated DFLT_ESC_SUB (since it isn't an arbitrarily chosen value). This is an approximation of the formula that Writer uses (since Writer does exact calculations based on each font's metrics). This Writer-inspired formula was introduced in LO 6.4 for more accurate exporting to MSO word processing formats (tdf#127316). Change-Id: I0267810efe31a2b3be41bf2d39e2278ce9bc99e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88911 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2019-12-03	remove some useless comment lines	Noel Grandin
	which merely announce that the next declaration is a class Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc Reviewed-on: https://gerrit.libreoffice.org/84229 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>