Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

26 Март 2017, 10:15 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Здесь можно поблагодарить участников форума Улыбка
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: « 1 2   Вниз
  Печать  
Автор Тема: Продолжение таблицы на следующей странице  (Прочитано 1088 раз)
0 Пользователей и 1 Гость смотрят эту тему.
kompilainenn
Ветеран
*****
Offline Offline

Сообщений: 1 911



« Ответ #15: 10 Январь 2017, 13:39 »

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

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

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 375


« Ответ #16: 10 Январь 2017, 13:40 »

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

С уважением,
Михаил Каганский
McAaron
Постоялец
***
Offline Offline

Сообщений: 141


« Ответ #17: 10 Январь 2017, 14:05 »

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

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

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

Записан
mikekaganski
Старожил
****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 375


« Ответ #18: 10 Январь 2017, 14:08 »

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

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

С уважением,
Михаил Каганский
kompilainenn
Ветеран
*****
Offline Offline

Сообщений: 1 911



« Ответ #19: 10 Январь 2017, 15:07 »

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

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

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 375


« Ответ #20: 10 Январь 2017, 15:10 »

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

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

С уважением,
Михаил Каганский
McAaron
Постоялец
***
Offline Offline

Сообщений: 141


« Ответ #21: 11 Январь 2017, 16:18 »

А что тут отвечать? Я не знаю, о чём тут говорится. У нас нормальный код, работающий с 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
Старожил
****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 375


« Ответ #22: 11 Январь 2017, 16:24 »

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

С уважением,
Михаил Каганский
McAaron
Постоялец
***
Offline Offline

Сообщений: 141


« Ответ #23: 11 Январь 2017, 17:17 »

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
Старожил
****
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 375


« Ответ #24: 11 Январь 2017, 17:25 »

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

С уважением,
Михаил Каганский
bormant
Глобальный модератор
*
Offline Offline

Сообщений: 894



« Ответ #25: 11 Январь 2017, 19:06 »

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

Автору на яд. Поддержать форум.
McAaron
Постоялец
***
Offline Offline

Сообщений: 141


« Ответ #26: 11 Январь 2017, 19:36 »

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

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 375


« Ответ #27: 11 Январь 2017, 20:23 »

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

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

С уважением,
Михаил Каганский
McAaron
Постоялец
***
Offline Offline

Сообщений: 141


« Ответ #28: 16 Январь 2017, 20:23 »

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

* test.002.gz (2.26 Кб - загружено 4 раз.)
Записан
Страниц: « 1 2   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!