Продолжение таблицы на следующей странице

[kompilainenn]

https://bugs.documentfoundation.org/show_bug.cgi?id=103391

и заброшено, судя по вопросу Яна

[mikekaganski]

нет, бубли прямо сейчас разговаривает с новым контрибутором

[McAaron]

.. подпункт 4.4.7 ГОСТ 2.105-95 во втором абзаце был дополнен словами: "При подготовке текстовых документов с использованием программных средств надпись "Продолжение таблицы" допускается не указывать".

Спасибо за подсказку -- это реально помогло в битве с нормоконтролером

... может впрягетесь пилить код Либры на общественных началах? Они там пилят кто что хочет и кому что ближе.

Может бы и впрягся, если бы программная документация проекта была доступна. Летом достаточно подробно посмотрел код, который можно скачать для сборки своих бинарников, на предмет того, чтобы вернуть взад системные шрифты в стилевых перечнях. Был крайне удивлен тем, что для работы с мультибайтным текстом и юникодом используется самопальный код времен раннего старофиса вместо того, чтобы использовать средства С++, входящие в состав стандартной библиотеки. Как говорится, пахнуло темными временами восьмибайтных кодировок.

Ах да, никто же не заставляет пользоваться именно Либрой. Пользуйтесь профессиональным МС Вьорд, у него там профессиональные возможности развиты, как нигде в мире, да

Ага, профессиональный -- попробуйте в этом Вашем "МС Вьорд" установить горизонтальные метрики для перечней -- забодаетесь искать как и где. Профессиональный -- это латех. К сожалению, им владеют не только лишь все...

[mikekaganski]

.. подпункт 4.4.7 ГОСТ 2.105-95 во втором абзаце был дополнен словами: "При подготовке текстовых документов с использованием программных средств надпись "Продолжение таблицы" допускается не указывать".

Спасибо за подсказку -- это реально помогло в битве с нормоконтролером

Рад за Вас - но на самом деле это неверно: в изменении 1 к самому ГОСТ 7.32 эта ссылка убрана. Наши нормоконтролёры так же ошибаются

[kompilainenn]

Был крайне удивлен тем, что для работы с мультибайтным текстом и юникодом используется самопальный код времен раннего старофиса вместо того, чтобы использовать средства С++, входящие в состав стандартной библиотеки. Как говорится, пахнуло темными временами восьмибайтных кодировок.

вот! отвечает mikekaganski!

[mikekaganski]

Был крайне удивлен тем, что для работы с мультибайтным текстом и юникодом используется самопальный код времен раннего старофиса вместо того, чтобы использовать средства С++, входящие в состав стандартной библиотеки. Как говорится, пахнуло темными временами восьмибайтных кодировок.

вот! отвечает mikekaganski!

А что тут отвечать? Я не знаю, о чём тут говорится. У нас нормальный код, работающий с Unicode, и мне хотелось бы поинтересоваться, какие конкретные средства стандартной библиотеки имелись ввиду.

[McAaron]

А что тут отвечать? Я не знаю, о чём тут говорится. У нас нормальный код, работающий с Unicode, и мне хотелось бы поинтересоваться, какие конкретные средства стандартной библиотеки имелись ввиду.

Имелось ввиду то, что объявлено в include/rtl, include/sal. , типа sal_Unicode и много чего остального sal_*
Насколько я понял, rtl и sal -- это платформенно независимые строки и интегральные типы. Но платформенно независимые строки поддерживаются в C++ искаропки, как минимум, со стандарта С++98, причем двумя способами -- в виде чисто сишного интегрального типа wchar_t и в виде крестового фундаментального wchar_t. Поэтому возникает вопрос -- что такого есть в sal и rtl, чего нет в <wstring> и <cwchar> (wchar.c)?
Там же определена куча интегральных типов фиксированой длины типа sal_Int8/16/32 которые и без того определены в stdint.h, который опять же есть обязательная часть стандарта. На эти вопросы я себе ответил так -- это все осталось от того само старофиса, который имел свою собственную кнопку "пуск" в своем собственном окне:-)

[mikekaganski]

sal = system abstraction layer
Часть объявлений, которые действиельно не требуются, убраны и убираются. Например, sal_Bool. Но не всё так просто.
Стандарт определяет wchar_t, но не определяет его размер. А это критичная информация при работе с файлами, которые переносятся между системами. На некоторых системах он бывает 32 бита.
Насчёт обязательной части стандарта, в которой определены интегральные типы разного размера - это Вы зря. Это появилось только в последних редакциях стандарта, и не всеми компиляторами до сих пор нормально поддерживается.

[McAaron]

sal = system abstraction layer
Часть объявлений, которые действиельно не требуются, убраны и убираются. Например, sal_Bool. Но не всё так просто.
Стандарт определяет wchar_t, но не определяет его размер. А это критичная информация при работе с файлами, которые переносятся между системами. На некоторых системах он бывает 32 бита.

Так wchar_t это внутренний тип данных и он не должен пересекать границу блока "процессор-память", так же как и все остальные резиновые типы, встроенные в си. wchar_t связывается с файловой системой через locale. Как только Вы сказали, что у Вас, например, ru_RU.UTF8, так все преобразования wchar_t <--> unicode выполняются автоматом на уровне потокового ввода-вывода <cstdio>. То же самое будет, если у вас восьмибитная локаль -- wchar_t отлично будет преобразовываться из/в cp1251, например. Нужно только конкретно эту локаль указать. И только на уровне системного ввода-вывода нужно иметь собственную сериализацию.
А резиновые типы никто в файлы и не пишет -- для этого есть фиксаты из <cstdint>

Насчёт обязательной части стандарта, в которой определены интегральные типы разного размера - это Вы зря. Это появилось только в последних редакциях стандарта, и не всеми компиляторами до сих пор нормально поддерживается.

А какими компиляторами кроме gcc собирают офис? Cудя по исходникам, которые можно скачать, других как бы и не предусмотрено.

[mikekaganski]

1. Вы очень сильно упрощаете весь ввод-вывод потоками c++. Это абстракция, которая практически не используется в LO, потому что очень неудобна для принятой здесь модели.
2. Например, VC++

[bormant]

Да-да, любые сколь угодно сложные проблемы имеют тривиальные (или хотя бы простые), понятные, самоочевидные, решения. Жаль только все таковые либо неправильные, либо нереализуемые...

[McAaron]

1. Вы очень сильно упрощаете весь ввод-вывод потоками c++. Это абстракция, которая практически не используется в LO, потому что очень неудобна для принятой здесь модели.
2. Например, VC++

1. Под потоковым вводом-выводом я имел ввиду не <iostream>, а то, что работает через классический объект cstdio::FILE -- он платформенно-независимый. Тройка <cstdio>, <cwchar> и <clocale> накрывает все, что связано с текстом в разных кодировках.
Даже MSVC поддерживает это, если верить MSDN -- все это помечено как полностью совместимое со стандартом С++11.
2. Да, нашел проект в каталоге windows ...

[mikekaganski]

Тройка <cstdio>, <cwchar> и <clocale> накрывает все, что связано с текстом в разных кодировках.

Снова невообразимое упрощение.
Стандартные классы c++ обеспечивают основные возможности, которые нужны 90% программ. Не нужно думать, что они способны обеспечить все возможные вариации. Тем более когда речь идёт о возможностях работать с не-BMP codepoints, заниматься нормализацией и выводом combined characters и т.д., что в стандартных библиотеках вообще не реализуется, а то, что там есть, либо неправильно работает, либо несовместимо, либо неоптимально...
Кстати, в LO одна из наиболее агрессивных политик использования новых возможностей c++, и если что-то вообще возможно применить и оно реализовано на трёх основных компиляторах, то это используется обязательно.

[McAaron]

не-BMP codepoints

Это то, что во вложении?