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

Автор McAaron, 7 января 2017, 14:49

0 Пользователи и 1 гость просматривают эту тему.

kompilainenn

Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут

mikekaganski

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

McAaron

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

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

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


mikekaganski

Цитата: McAaron от 10 января 2017, 14:05
Цитата: bormant от  7 января 2017, 18:29
.. подпункт 4.4.7 ГОСТ 2.105-95 во втором абзаце был дополнен словами: "При подготовке текстовых документов с использованием программных средств надпись "Продолжение таблицы" допускается не указывать".
Спасибо за подсказку -- это реально помогло в битве с нормоконтролером

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

kompilainenn

Цитата: McAaron от 10 января 2017, 12:05Был крайне удивлен тем, что для работы с мультибайтным текстом и юникодом используется самопальный код времен раннего старофиса вместо того, чтобы использовать средства С++, входящие в состав стандартной библиотеки. Как говорится, пахнуло темными временами восьмибайтных кодировок.
вот! отвечает mikekaganski!
Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут

mikekaganski

Цитата: kompilainenn от 10 января 2017, 15:07
Цитата: McAaron от 10 января 2017, 12:05Был крайне удивлен тем, что для работы с мультибайтным текстом и юникодом используется самопальный код времен раннего старофиса вместо того, чтобы использовать средства С++, входящие в состав стандартной библиотеки. Как говорится, пахнуло темными временами восьмибайтных кодировок.
вот! отвечает mikekaganski!

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

McAaron

Цитата: mikekaganski от 10 января 2017, 15:10
А что тут отвечать? Я не знаю, о чём тут говорится. У нас нормальный код, работающий с 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

Цитата: mikekaganski от 11 января 2017, 16:24
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>

Цитата: mikekaganski от 11 января 2017, 16:24
Насчёт обязательной части стандарта, в которой определены интегральные типы разного размера - это Вы зря. Это появилось только в последних редакциях стандарта, и не всеми компиляторами до сих пор нормально поддерживается.
А какими компиляторами кроме gcc собирают офис? Cудя по исходникам, которые можно скачать, других как бы и не предусмотрено.


mikekaganski

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

bormant

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

McAaron

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

mikekaganski

Цитата: McAaron от 11 января 2017, 19:36
Тройка <cstdio>, <cwchar> и <clocale> накрывает все, что связано с текстом в разных кодировках.

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

McAaron