[Libreoffice-commits] core.git: editeng/source vcl/source

[Andrea Gelmini]

 editeng/source/items/frmitems.cxx |    4 ++--
 vcl/source/app/salvtables.cxx     |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

New commits:
commit f7be5817ca96d415a99e0bea9757fc3899572263
Author: Andrea Gelmini <andrea.gelmini at gelma.net>
Date:   Fri Mar 16 07:30:23 2018 +0100

    Fix typos
    
    Change-Id: If70b03cad4c46010a59cf3bee139e801230fa3aa
    Reviewed-on: https://gerrit.libreoffice.org/51385
    Tested-by: Jenkins <ci at libreoffice.org>
    Reviewed-by: Julien Nabet <serval2412 at yahoo.fr>

diff --git a/editeng/source/items/frmitems.cxx b/editeng/source/items/frmitems.cxx
index ea1d15126ff3..6b60d5a4ffaa 100644
--- a/editeng/source/items/frmitems.cxx
+++ b/editeng/source/items/frmitems.cxx
@@ -2638,7 +2638,7 @@ void BorderDistanceFromWord(bool bFromEdge, sal_Int32& nMargin, sal_Int32& nBord
 // border position (modulo rounding errors):
 // 1. When distance of all borders from text is no greater than 31 pt, we use "from text"
 // 2. Otherwise, if distance of all borders from edge is no greater than 31 pt, we use "from edge"
-// In all other cases, the position of borders would be distirted on export, because Word doesn't
+// In all other cases, the position of borders would be distorted on export, because Word doesn't
 // support the offset of >31 pts (https://msdn.microsoft.com/en-us/library/ff533820), and we need
 // to decide which type of offset would provide less wrong result (i.e., the result would look
 // closer to original). Here, we just check sum of distances from text to borders, and if it is
@@ -2648,7 +2648,7 @@ void BorderDistanceFromWord(bool bFromEdge, sal_Int32& nMargin, sal_Int32& nBord
 void BorderDistancesToWord(const SvxBoxItem& rBox, const WordPageMargins& rMargins,
     WordBorderDistances& rDistances)
 {
-    // Use signed sal_Int32 that can hold sal_uInt16, to prevent overflow at substraction below
+    // Use signed sal_Int32 that can hold sal_uInt16, to prevent overflow at subtraction below
     const sal_Int32 nT = rBox.GetDistance(SvxBoxItemLine::TOP);
     const sal_Int32 nL = rBox.GetDistance(SvxBoxItemLine::LEFT);
     const sal_Int32 nB = rBox.GetDistance(SvxBoxItemLine::BOTTOM);
diff --git a/vcl/source/app/salvtables.cxx b/vcl/source/app/salvtables.cxx
index 15d44f892a76..ffcb468a458e 100644
--- a/vcl/source/app/salvtables.cxx
+++ b/vcl/source/app/salvtables.cxx
@@ -1202,7 +1202,7 @@ IMPL_LINK(SalInstanceDrawingArea, MouseReleaseHdl, const Point&, rPos, void)
     m_aMouseReleaseHdl.Call(rPos);
 }
 
-//ComboBox and ListBox have similiar apis, ComboBoxes in LibreOffice have an edit box and ListBoxes
+//ComboBox and ListBox have similar apis, ComboBoxes in LibreOffice have an edit box and ListBoxes
 //don't. This distinction isn't there in Gtk. Use a template to sort this problem out.
 template <class vcl_type>
 class SalInstanceComboBoxText : public SalInstanceContainer, public virtual weld::ComboBoxText