See http://www.w3.org/TR/html-markup/documents.html#conformant-html

Change-Id: Id2835f20baad20bcb874df5e6f35a189c320367b
Reviewed-on: https://gerrit.libreoffice.org/8079Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I6ad4d730b4b8d715fcab20c09d654e5aa57465d5

8f8bc0dc "Move string hash function into String
class" had introduced a new getHash64 that, besides returning sal_uInt64 instead
of just sal_Int32, didn't do sampling of only a handful of characters, but
always computed the hash over all characters (as the usage in SfxItemSet and
SdPage appears to require for either performance or approximated correctness).

However, it would be advantageous to keep the stable URE interface as small as
possible.  Now, O(1) sampling was apparently considered state of the art when
the rtl string classes were first created, closely copying java.lang.String,
which at that time demanded sampling for hashCode(), too---but never sampling
more than 15 characters, with the obvious (in hindsight, at least) performance
catastrophes, so they changed it to O(n) somewhere along the way.

Based on that, this commit changes the existing hash functions to not do
sampling any more, and removes the newly introduced -64 variants again.  (Where
the extended value range of sal_uInt64 compared to sal_Int32 was hopefully not
vital to the existing uses.)

The old implementation used sampling only for strings of length >= 256, so I did
a "make check" build with an instrumented hash function that flagged all uses
with inputs of length >= 256, and grepped workdir/{Cppunit,Junit,Python}Test for
hits.  Of the 2849 hits encountered, 2845 where in the range from 256 to 295
characters, and only the remaining four where of 2472 characters.  Those four
were from CppunitTest_sc_subsequent_filters_test, importing long text into a
cell, causing ScDocumentImport::setStringCell to call
svl::SharedStringPool::intern, which internally uses an unordered_set.  These
results appear to justify the change.

Change-Id: I78fcc3b0f07389bdf36a21701b95a1ff0a0d970f

Change-Id: I35f302006cb9ef6e98a041dea811818b98c0e876

In this document written by "XMLmind XSL-FO Converter" there are less
\cellx than \cell and thus when reading \nestrow/\row a whole buffered
nested table \cell is lost and then subsequently the rest of the nested
table too.  Try to fix that by counting both \cell and \cellx and
replaying until the maximum of those.

Cannot count \intbl since we synthesize that in various places.

(regression in LO 3.5)

Change-Id: I3b64ad94af842e076611418589a0c83bd18841c6

Change-Id: I5fe47cfaee84c17584ba7c3d160e65b55f4e3474

Change-Id: I08d4de5fc4cbc56feda0f57f95ae76cd25b124e3

(cherry picked from commit bc34afeb)

Change-Id: I0ef0d1a8b35ed6eb30db3d116bb102a911006ca0

Change-Id: Ibaeaa95c346547f17b82c687944a8b37c05b9b49

Change-Id: I2f6b40def145ea478403fb566c4b0d57c87c0627

Change-Id: I871fcd02f461c798520a033217e14b3caa78876e

Change-Id: I66b660ac2efa59a64a9d188dee3965243b0fa435

Change-Id: Ie975f8a970eec63b593933ebb2394db76d537c51

Change-Id: I02fa1aea1070a6485b96a67f7d6f7f56c022bd9e

Change-Id: Id1d838fe4316bbc0e1137d395bb15db3585aed84

Change-Id: I60233fdc8d03e2d0dae03eaa8f3ef47ad8bdf43e

Change-Id: I114abdb07760e128e40a6e4a82d276584aabed97

Change-Id: If67e1c48fba43fabcaffef92d96bc1377b4d1dd8

Change-Id: I6a90bbc1fc2faa379a72dd0a61dd96a829676e2c

I was getting crashes during editing with notes; unfortunately I am unable to
reproduce it reliably, so I am not 100% sure this is the right fix - but I
hope so.

This is what valgrind was suggesting:

==21766== Invalid read of size 8
==21766==    at 0x285AF9C7: std::__debug::list<SwSidebarItem*, std::allocator<SwSidebarItem*> >::remove(SwSidebarItem* const&) (list:569)
==21766==    by 0x285A2BFC: SwPostItMgr::RemoveItem(SfxBroadcaster*) (PostItMgr.cxx:241)
==21766==    by 0x285A3241: SwPostItMgr::Notify(SfxBroadcaster&, SfxHint const&) (PostItMgr.cxx:346)
==21766==    by 0x84AFB1E: SfxBroadcaster::Broadcast(SfxHint const&) (brdcst.cxx:46)
...
==21766==    by 0xA5A3C74: Application::Yield() (svapp.cxx:393)
==21766==    by 0xA5A3C20: Application::Execute() (svapp.cxx:342)
==21766==    by 0x50EA0F4: desktop::Desktop::Main() (app.cxx:1678)
...
==21766==  Address 0x2e2824f0 is 16 bytes inside a block of size 24 free'd
==21766==    at 0x4C2AA9C: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21766==    by 0x285B4B85: __gnu_cxx::new_allocator<std::__cxx1998::_List_node<SwSidebarItem*> >::deallocate(std::__cxx1998::_List_node<SwSidebarItem*>*, unsigned long) (new_allocator.h:100)
==21766==    by 0x285B40C1: std::__cxx1998::_List_base<SwSidebarItem*, std::allocator<SwSidebarItem*> >::_M_put_node(std::__cxx1998::_List_node<SwSidebarItem*>*) (stl_list.h:339)
==21766==    by 0x285B43BB: std::__cxx1998::list<SwSidebarItem*, std::allocator<SwSidebarItem*> >::_M_erase(std::__cxx1998::_List_iterator<SwSidebarItem*>) (stl_list.h:1549)
==21766==    by 0x285B346E: std::__cxx1998::list<SwSidebarItem*, std::allocator<SwSidebarItem*> >::erase(std::__cxx1998::_List_iterator<SwSidebarItem*>) (list.tcc:113)
==21766==    by 0x285B18EB: std::__debug::list<SwSidebarItem*, std::allocator<SwSidebarItem*> >::_M_erase(std::__cxx1998::_List_iterator<SwSidebarItem*>) (list:423)
==21766==    by 0x285AF9E6: std::__debug::list<SwSidebarItem*, std::allocator<SwSidebarItem*> >::remove(SwSidebarItem* const&) (list:570)
==21766==    by 0x285A2BFC: SwPostItMgr::RemoveItem(SfxBroadcaster*) (PostItMgr.cxx:241)
==21766==    by 0x285A3241: SwPostItMgr::Notify(SfxBroadcaster&, SfxHint const&) (PostItMgr.cxx:346)
==21766==    by 0x84AFB1E: SfxBroadcaster::Broadcast(SfxHint const&) (brdcst.cxx:46)
...
==21766==    by 0xA5A3C74: Application::Yield() (svapp.cxx:393)
==21766==    by 0xA5A3C20: Application::Execute() (svapp.cxx:342)
==21766==

Change-Id: I0ed3e09338810200766bd10203d9fcac26e822f6

It implements extension manager which we hopefully don't need.

After b14218e4709a7a5961f1564543da35788b578014 it should finally work.

Change-Id: I366722cc77de69c4937d461fed917e350b1b5fa5

Change-Id: Ic49a22140233e72e6f1e103558825970f1ee3df3

This can happen for mobile platforms where we don't need singletons
like com.sun.star.deployment.ExtensionManager.

Change-Id: Iad6729539c7ed1ad2b3315c7b9a35647e92ebbff

Change-Id: Ieba5e6b1c1f32125a4c266e5252d9c1bc729f061

Change-Id: I628c1506573c7d5ec182048a20ed996c9ae879c4

Change-Id: I7ebc6d5271321072469665f055f49b1dd2d98b93

Change-Id: Iee89a55e2a8d98b1d4afa371695ae25e84288ae7

Change-Id: I84c4e3ae602f12a359f699a9c87bec0201b0e0ff

Change-Id: I630f398abbe929f9f0b035b2410d92496b609528

Change-Id: I87be0ac485f717bfdd3340143fb08a49ed071653

Change-Id: If9651e839831245119f22d04b241e520a7b757b5

Change-Id: I906c191f2adb50419952993d4cb946e097d4e5f7

Change-Id: Ifa9fe7e2b24ac74f51341b5a86b5ff241b99459a

Change-Id: Ief6804e2604618162bd6fc87985dbee474492aff

Change-Id: I98448e4276acbbcd754f0573dcec9a16ef814174

Change-Id: If00756cdecc19f5a0159921833a24490b9d70450

Change-Id: I3c91fbe6f7cc383815a3492be72642e968d48327

Change-Id: Ifc854ea58b04c21584b8eb9c00299c8e27f81a1f

Change-Id: Ibd9ad76c9580496f3ff8ec256656c816a36f0892

Change-Id: I04b1fd1bafdb8760b2fa08813ea21614ddbbf918