# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
#
# This file is part of the LibreOffice project.
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#

$(eval $(call gb_Package_Package,extras_tplpersonal,$(call gb_CustomTarget_get_workdir,extras/source/templates/personal)))

$(eval $(call gb_Package_add_files,extras_tplpersonal,$(LIBO_SHARE_FOLDER)/template/common/personal,\
	CV.ott \
	Resume1page.ott \
))

# vim: set noet sw=4 ts=4:
blem that pdfparse::PDFReader::read couldn't create file_iterator
for files already opened with write access: mmap_file_iterator ctor
on Windows used single FILE_SHARE_READ as dwSharedMode parameter for
CreateFileA WinAPI; and that failed, when the file was already opened
using GENERIC_WRITE in dwDesiredAccess - which happens when opening
stream in TypeDetection::impl_detectTypeFlatAndDeep.

Fix this by patching boosts' mmap_file_iterator constructor to use
FILE_SHARE_READ | FILE_SHARE_WRITE, like we do in osl_openFile.

But there was a pre-existing problem of using char-based CreateFileA
API, which disallows opening any files with names not representable
in current Windows codepage. Such hybrid PDF files would still fail
creation of the file_iterator, and open as PDF.

Fix that by further patching boost to have wstring-based constructors
for file_iterator and mmap_file_iterator on Windows, which would call
CreateFileW.

Change-Id: Ib190bc090636159ade390b3dd120957d06d7b89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160218
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 046e9545956d8ad1d69345d6b4a4c0a33714d179 (Try to revert to use
of file_iterator from boost on Windows, 2023-10-31) had introduced a
problem that pdfparse::PDFReader::read couldn't create file_iterator
for files already opened with write access: mmap_file_iterator ctor
on Windows used single FILE_SHARE_READ as dwSharedMode parameter for
CreateFileA WinAPI; and that failed, when the file was already opened
using GENERIC_WRITE in dwDesiredAccess - which happens when opening
stream in TypeDetection::impl_detectTypeFlatAndDeep.

Fix this by patching boosts' mmap_file_iterator constructor to use
FILE_SHARE_READ | FILE_SHARE_WRITE, like we do in osl_openFile.

But there was a pre-existing problem of using char-based CreateFileA
API, which disallows opening any files with names not representable
in current Windows codepage. Such hybrid PDF files would still fail
creation of the file_iterator, and open as PDF.

Fix that by further patching boost to have wstring-based constructors
for file_iterator and mmap_file_iterator on Windows, which would call
CreateFileW.

Change-Id: Ib190bc090636159ade390b3dd120957d06d7b89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160218
Tested-by: Jenkins
Reviewed-by: Mike Kaganski &lt;mike.kaganski@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Introduce o3tl::toU converting wstring_view to u16string_view</title>
<updated>2023-04-22T10:46:01+00:00</updated>
<author>
<name>Mike Kaganski</name>
<email>mike.kaganski@collabora.com</email>
</author>
<published>2023-04-22T08:28:20+00:00</published>
<link rel='alternate' type='text/html' href='https://go.suokunlong.cn:88/cgit/lo/core/commit/?id=0f6ec3939df6b0e3263fc07a2067bbbfc6421ac7'/>
<id>0f6ec3939df6b0e3263fc07a2067bbbfc6421ac7</id>
<content type='text'>
Change-Id: I5be9aa767020c2516984e47fcd0f51d4661fdf17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski &lt;mike.kaganski@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change-Id: I5be9aa767020c2516984e47fcd0f51d4661fdf17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski &lt;mike.kaganski@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>clang-format char16_t2wchar_t.hxx</title>
<updated>2023-04-22T10:45:38+00:00</updated>
<author>
<name>Mike Kaganski</name>
<email>mike.kaganski@collabora.com</email>
</author>
<published>2023-04-22T08:25:57+00:00</published>
<link rel='alternate' type='text/html' href='https://go.suokunlong.cn:88/cgit/lo/core/commit/?id=ab55c7bffddc1a4c8f3d971d24bae297a15f3346'/>
<id>ab55c7bffddc1a4c8f3d971d24bae297a15f3346</id>
<content type='text'>
Change-Id: I5b86fb372702e3a6fdb3e4aa6846c4bc2e754307
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150778
Tested-by: Jenkins
Reviewed-by: Mike Kaganski &lt;mike.kaganski@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change-Id: I5b86fb372702e3a6fdb3e4aa6846c4bc2e754307
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150778
Tested-by: Jenkins
Reviewed-by: Mike Kaganski &lt;mike.kaganski@collabora.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Rename and move SAL_U/W to o3tl::toU/W</title>
<updated>2017-10-05T14:02:52+00:00</updated>
<author>
<name>Mike Kaganski</name>
<email>mike.kaganski@collabora.com</email>
</author>
<published>2017-10-05T03:19:56+00:00</published>
<link rel='alternate' type='text/html' href='https://go.suokunlong.cn:88/cgit/lo/core/commit/?id=1944e3ddc0b2247de3138d2a441cd6999e21fd9a'/>
<id>1944e3ddc0b2247de3138d2a441cd6999e21fd9a</id>
<content type='text'>
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b)
it was expected to gradually remove SAL_U/W usage in Windows code
by replacing with reinterpret_cast or changing to some bettertypes.
But as it's useful to make use of fact that LibreOffice and Windows
use compatible representation of strings, this commit puts these
functions to a better-suited o3tl, and recommends that the functions
be consistently used throughout Windows-specific code to reflect the
compatibility and keep the casts safe.

Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6
Reviewed-on: https://gerrit.libreoffice.org/43150
Tested-by: Jenkins &lt;ci@libreoffice.org&gt;
Reviewed-by: Mike Kaganski &lt;mike.kaganski@collabora.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b)
it was expected to gradually remove SAL_U/W usage in Windows code
by replacing with reinterpret_cast or changing to some bettertypes.
But as it's useful to make use of fact that LibreOffice and Windows
use compatible representation of strings, this commit puts these
functions to a better-suited o3tl, and recommends that the functions
be consistently used throughout Windows-specific code to reflect the
compatibility and keep the casts safe.

Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6
Reviewed-on: https://gerrit.libreoffice.org/43150
Tested-by: Jenkins &lt;ci@libreoffice.org&gt;
Reviewed-by: Mike Kaganski &lt;mike.kaganski@collabora.com&gt;
</pre>
</div>
</content>
</entry>