Czcionka w tekście - brak polkich znaków

[Jactra]

Mam wzór umowy jak w załączniku.
Problem polega na tym, że jest to z zewnętrznego programu dokument gotowy do edycji (z programu klikam na "Otwórz do edycji" i otwiera mi się dokument w LibreOffice.
No i tutaj są schody : po otwarciu dokumentu brak jest polskich znaków (ą, ś, ł, ż itd) zaś zamiast tego jest taki tekst, jak w załączniku.

Jest jakiś "hurtowy" sposób na zmianę tego ?
Dokument jest zrobiony jako .rtf. Czcionka, która się wyświetla w LibreOffice to Time New Roman CE.
Z takimi krzaczkami wyświetla się w LibreOffice, jak i OpenOffice. Poprawnie jest jedynie w MS Office (Word).

[bogdans]

Gdzie jest ten załącznik?

[Jan_J]

Czcionki CE to jakiś relikt z okresu 256-znakowych kodowań. W Viście raczej ich nie masz, są tam raczej fonty unikodowe. W takim przypadku zawartość jest wyświetlana przy użyciu innej czcionki. A że font CE raczej wymaga innego kodowania znaków niż unikodowy, to i mamy problem.

Regułami postawiania czcionek (tzw. tablicą konwersji fontów) możesz sobie zarządzać. Ale żeby kodowaniem znaków, to już nie sądzę.

[Jactra]

Nie spojrzałem, że dodawanie RTF-ów jest zablokowane.
Zapisałem jako .odt.

Jan_J : to co w takim razie zrobić, żeby było poprawnie ?
Dlaczego w takim razie, skoro w Viście nie znajdę takiej czcionki MS Office (Word) 2007 wyświetla plik poprawnie ?

[bogdans]

I co z tym plikiem mam zrobić? Może spakuj rtf, albo zmień mu rozszerzenie.

[Jactra]

I co z tym plikiem mam zrobić? Może spakuj rtf, albo zmień mu rozszerzenie.

Nie za bardzo rozumiem....
Zapisz na dysk albo PPP i "Edytuj". Otworzy się do edycji.
Tak Libre wyświetla pliki jako załączniki. Obojętnie, czy jest to załącznik na forum, czy jako załącznik e-mail. Zawsze jest "tylko do odczytu".
A rozszerzenie jest prawidłowe .odt. Jak zauważyłem poza PDF i natywnymi plikami .odt i.ods forum nie pozwala załączać.

[Jan_J]

Dlaczego w takim razie, skoro w Viście nie znajdę takiej czcionki MS Office (Word) 2007 wyświetla plik poprawnie ?

Pewnie wie, jako podmienić font w układzie CE na unikodowy.

RTF jest formatem tekstowym. Możesz zajrzeć do kodu dokumentu, żeby sprawdzić czy mam rację. Znaki specjalne będą tam widoczne jako \numer, być może poprzedzone symbolem kodowania.

[Jan_J]

[...] poza PDF i natywnymi plikami .odt i.ods forum nie pozwala załączać.

Zaszłości spowodowane nadmierną ostrożnością. Zawsze można opracować w zip-a.
Odblokowałem formaty dokumentów, m.in. rtf. Jeśli spadnie przez to kultura przekazu, w co nie wierzę, zawsze można z powrotem zablokować.

[Jactra]

Pewnie wie, jako podmienić font w układzie CE na unikodowy.

RTF jest formatem tekstowym. Możesz zajrzeć do kodu dokumentu, żeby sprawdzić czy mam rację. Znaki specjalne będą tam widoczne jako \numer, być może poprzedzone symbolem kodowania.

Ok, ale co z tym zrobić, żeby w LibreOffice wyświetlało się poprawnie ?
To jest plik z bazy prawnej. Część wzorów i dokumentów (myślę, że robionych kilka lat temu o ile wiem jeszcze za czasów MS Office 2000-2003) jest w .rtf. Część już w .doc i .xls. Te zrobione w .doc a otwarte w Libre są ok. W .rtf jak w załączniku.
Pal licho, że wyświetla się nie poprawnie. Zależy mi na tym, żeby znaleźć sposób na hurtową zmianę tych "krzaczków" na polskie znaki.

Generalnie w firmie wolę używać Libre niż MS Office 2007. Jakoś w Libre bardziej mogę się odnaleźć niż w MS Office jeśli chcę coś zrobić (np. jakiś szablon), chociaż obiektywnie patrząc wizualnie MS Office jest fajniejszy. Ale wstążka nie jest dla mnie najlepszym rozwiązaniem - niektóre funkcje ciężko jest znaleźć. Podstawowe są "na wierzchu", ale jak się coś chce zrobić bardziej zaawansowanego to można się naszukać.

[Jan_J]

Jak masowe, to się sprowadzi do wykrycia, jakiego kodowania użyto w oryginalnych plikach, i zastąpienia go kodowaniem utf-8. sed, awk, tr lub podobne narzędzia. Nie wiem, czy da się użyć konwertorów z interfejsem graficznym, bo znaki w pliku źródłowym mogą być zakodowane.

Podeślij próbkę rtf-a, zajrzę, żeby mieć pewność diagnozy.

[bogdans]

jactra napisał

Nie za bardzo rozumiem....

A co tu jest do rozumienia? Plik w formacie ODT jest już źle wczytany, konieczny jest oryginał. Jeżeli pliki ODT są dopuszczalne, to zmień nazwę Umowa.rtf na Umowa.odt i zamieść załącznik o nazwie Umowa.odt, informując jednocześnie, że tak zrobiłeś.

[Jactra]

Właśnie tak zrobiłem.
A zapytałeś co masz zrobić z tym plikiem....

To jest oryginalny otworzony plik, a zapisany jedynie jako .odt.
Nie robiłem tego na zasadzie kopiuj/wklej.

[Jan_J]

Nie spojrzałem, że dodawanie RTF-ów jest zablokowane.
Zapisałem jako .odt.

Jan_J : to co w takim razie zrobić, żeby było poprawnie ?
Dlaczego w takim razie, skoro w Viście nie znajdę takiej czcionki MS Office (Word) 2007 wyświetla plik poprawnie ?

Zajrzałem do Umowa.odt. Jest tak jak myślałem: znaki są kodowane de facto w cp1250, a deklaracja jest w UTF-8, zresztą taka musi być w ODT. RTF sam z siebie nie wymaga żadnego szczególnego kodowania, i jemu to nie szkodzi. Być może kodowanie da się wydedukować z RTF-a, a filtr importu nie bierze tego pod uwagę. Możliwe też, że deklaracji kodowania tam nie ma, a Word “znając” swoje formaty zgaduje kodowanie i się nie myli.

[Jactra]

Dzięki.

Czyli de facto nic się z tym nie da zrobić ?

[Jan_J]

Jest jak mówiłem.
RTF jest prostym formatem i wiele da się zrobić prostymi narzędziami.

Jeżeli chodzi o duży zbiór gotowych plików, to proponowałbym zapuścić konwerter i już.
Jeżeli pliki są generowane w jakimś systemie, sprawa się nieco komplikuje.

Podeślij RTF-a (powinno się już dać załączyć), zobaczę.

[Jactra]

Jan_J :
nNiestety (przy najmniej u mnie) standardowy konwenter w LibreOffice nie działa (Plik-> kreatory -> konwenter dokumentu). Wyrzuca mi błąd języka Basic.
Z kolei jeśli zapiszę plik w umową w .rtf to już w ogóle jest kaszana i po otwarciu go w Libre cały tekst jest .... w pionie.
Zresztą sam zobacz.

[Jan_J]

Jeżeli Twój odt został wygenerowany przez system, to wolę go używać zamiast RTF-a, bo przynajmniej layout jest zachowany.

Sprawa polega na przywróceniu numerów znaków unicode w miejsce dwóch innych numeracji. Pierwsza pochodzi ze wstawienia do unikodowego tekstu znaków o numerach odpowiadających kodowaniu cp1250, co jest konsekwencją założenia o stosowaniu 256-znakowego fontu CE. Druga wzięła się nie wiem skąd, prawdopodobnie z błędnego przekodowania pośredniego. Przykładem tego drugiego jest zniekształcenie kodu “ź” w słowie “październik”. Zakres znaków tego drugiego kodowania jest dla mnie niejasny i będzie go trzeba uzupełnić.

Na razie zbiory znaków sprzed i po korekcie są rozłączne, więc teoretycznie dwukrotna korekta nie powinna nic zepsuć. To się może zmienić, kiedy uzupełniony zostanie wspomniany drugi zestaw znaków.

Natomiast jeżeli dokument w intencji zawiera znaki unikodu o numerach takich, jak numery polskich liter w cp1250, to nie ma siły: zostanie uszkodzony. Są to znaki: Æœ£¥æÑꌯñ³Ÿ¹¿œÊŸ (nie wszystkie muszą być widoczne w przeglądarce).

W przypadku, kiedy wybrany plik nie będzie plikiem OpenDocument (ściślej: archiwum zip zawierającym plik content.xml), nie powinien w ogóle zostać zmodyfikowany w toku korekty.

Mimo wszystko pisząc “nie powinien / nie powinna” nie udzielam żadnej gwarancji bezpieczeństwa korygowanych plików; proszę samemu zadbać o kopie bezpieczeństwa.

Załączam korektor w postaci źródła (Python) oraz pliku odt zawierającym ten kod w sobie, i z przyciskiem uruchamiającym skrypt na żądanie. Po uruchomieniu pojawi się okno dialogowe, w którym da się zaznaczyć wiele plików. Raport z przebiegu korekty zostanie dopisany na końcu dokumentu z przyciskiem, można go zachować lub nie, zależnie od kaprysu.

Mam nadzieję, ze się przyda.

Może działać jako skrypt w OOo i w LO. Testowałem pod Linuksem; w Windows niespodzianek się nie spodziewam, ale zastrzegam że nie sprawdzałem. Licencja Public Domain, nie daję żadnych gwarancji.

Kod: Zaznacz cały

#!/usr/bin/env python
#coding: utf-8

import zipfile
import sys
import os
try:
    import unohelper
    IS_UNO = True
except ImportError:
    IS_UNO = False

'''
    Korekta kodowania zawartości pliku odt
    (w uzupełnieniu wątku http://user.services.openoffice.org/pl/forum/viewtopic.php?f=8&t=1175).
    Używasz na własną odpowiedzialność.
    Kod modułu jest własnością publiczną; możesz go dowolnie modyfikować.
    Wrocław, 14 stycznia 2012 r.
'''

zamiany = {
# cp1250 na unicode
    185: 261,
    230: 263,
    234: 281,
    179: 322,
    241: 324,
#    243: 243,
    156: 347,
    159: 378,
    191: 380,
    165: 260,
    198: 262,
    202: 280,
    163: 321,
    209: 323,
#    211: 211,
    140: 346,
    143: 377,
    175: 379,
# licho wi co na unicode
    339: 347,
    376: 378,
}

def zamien(n):
    try:
        return unichr(zamiany[ord(n)]), 1
    except:
        return n, 0

def jedenPopraw(fname):
    cxml = 'content.xml'
    try:
        z = zipfile.ZipFile(fname, 'r')
        d = list(z.read(cxml).decode('utf8'))
        n = 0
        for i in range(len(d)):
            d[i], res = zamien(d[i])
            n += res
        z.close()
        with open(cxml, 'w') as p:
            p.write(''.join(d).encode('utf8'))
        z = zipfile.ZipFile(fname, 'a')
        z.write(cxml)
        z.close()
        os.remove(cxml)
        return n
    except:
        return None

def masowoPopraw(fnames):
    msg = 'Wyniki korekty:\n'
    for fname in fnames:
        res = jedenPopraw(fname)
        msg += '%s:\t%s\n' % (('Pomyślna (liczba zamian: %i)' % res) if type(res) in (int, long) else 'Nieudana', fname.encode('utf8'))
    return msg

if IS_UNO:

    def OOoFileOpenDialog(ctx, fname, title, mode, multi = False):
        picker = ctx.ServiceManager.createInstanceWithContext("com.sun.star.ui.dialogs.FilePicker", ctx)
        picker.initialize( (mode, ) )
        fname = unohelper.systemPathToFileUrl(os.path.abspath(fname))
        picker.setDisplayDirectory(fname)
        picker.setTitle(title)
        picker.setMultiSelectionMode(multi)
        if picker.execute():
            fnames = picker.getFiles()
            if len(fnames) > 1:
                fnames = tuple([ unohelper.fileUrlToSystemPath(fnames[0] + item) for item in fnames[1:] ])
            else:
                fnames = (unohelper.fileUrlToSystemPath(fnames[0]),)
        else:
            fnames = ( )
        picker.dispose()
        return fnames

    def insertString(oDoc, msg):
        oText = oDoc.Text
        oCursor = oText.createTextCursor()
        oCursor.gotoEnd(False)
        oText.insertString(oCursor, msg, False)

    FILEOPEN_SIMPLE = 0
    FILESAVE_SIMPLE = 1

    def masowoPoprawDialog(evt = None):
        ctx = XSCRIPTCONTEXT.getComponentContext()
        if os.name == 'posix':
            wd = os.getenv('HOME')
        else:
            wd = os.getenv('USERPROFILE')
        listaplikow = OOoFileOpenDialog(ctx, wd, u'Wybierz pliki do korekty', mode = FILEOPEN_SIMPLE, multi = True)
        if listaplikow:
            os.chdir(wd)
            msg = masowoPopraw(listaplikow).decode('utf8')
            insertString(XSCRIPTCONTEXT.getDocument(), msg)

else:

    masowoPoprawDialog = None

g_exportedScripts = (masowoPoprawDialog,)

# end IS_UNO

if __name__ == '__main__':
    print masowoPopraw(sys.argv[1:])

[Jactra]

Jan_J dzięki, ale niestety wynik konwersji mam nie udany.

[Jan_J]

Podeślij plik, spróbujemy dostroić kody. Na Twoich wcześniejszych przykładach pracował, ale jak napisałem, nie wszytskie sytuacje były tam wyłapane.

[Jactra]

Ok, ale niestety tych plików nam kilkanaście-kilkadziesiąt.
Jak pisałem są one z zewnętrznej publikacjiniestety i potrzebne mi są w działalności.
Także naprawa jednego nic u mnie nie zmienia.
Ale wielkie dzięki za pomoc.

[Jan_J]

tych plików nam kilkanaście-kilkadziesiąt [...] i potrzebne mi są w działalności.Także naprawa jednego nic u mnie nie zmienia.

Właśnie dlatego pytam o przykład, żeby dostroić zakres zamienianych znaków.

Aha: korekta może nie działać na otwartym pliku...

W moim systemie Twoje załączniki (np. lex12.odt) konwertują się ładnie. Ot tak jak na obrazkach.
Sprawdzę jeszcze dzisiaj na stacjach z OOo 3.3 pod Windowsem.


PS. kierunek przepływu nagłówka jest dziwny, na to nie poradzę.

[Jactra]

Czyli u Ciebie działa.
U mnie nie chce.

[Jan_J]

Pod Windows:
* szczegóły z formatami tekstów przekazywanych do okienek
* szczegóły związane z konwersją nazwa pliku <--> url pliku
* szczegóły związane z uprawnieniami do zapisu wypakowanego pliku
nie były dopracowane.

Poprawiłem kod i załącznik, teraz działa i pod linuksem, i pod windą xp.

A poważnie, to sprawa nadaje się do zgłoszenie producentowi Lex-a, o ile tego jeszcze nie poprawili.

[Jactra]

Niestety.

Pobrałem jeszcze raz Twój plik. Podczas próby konwersji (po wskazaniu pliku do konwersji) wyrzuca komunikat błędu. Niestety po angielsku. Ale zrozumiałem tyle, że chodzi o coś z phytonem.
Dzieje się tak i pod LibreOffice 3.4.4 o OpenOffice 3.3

[Jan_J]

A bo sprawdzałem działanie pod Windows XP, ale na swoim koncie. A powinienem był pamiętać, że konfiguracja moich kont windowsowych jest nietypowa, po odtwarza część środowiska kont uniksowych. Nawet się dziwiłem trochę, że Windows ma zmienną środowiskową HOME, ale cóż: jeśli ma, to tym lepiej.
Poprawione, przetestowane z powodzeniem na koncie cudzym, typowo skonfigurowanym.

[Jactra]

Przepraszam, ale znowu mam wynik konwersji NIE UDANA.
Ściągnąłem ponownie ten plik, który zamieściłeś poprzednio.

[Jan_J]

Szkoda.
Podejrzewam problem albo w kodowaniu znaków w ścieżce pliku, albo w uprawnieniach do zapisu plików w kartotece (najwyraźniej potrzebne przy rozpakowywaniu, choć nie wiem dlaczego, przecież powinny iść do tmp). Ćwiczyłem jedno i drugie na XP, pod różnymi nazwami użytkowników, w różnych najdziwniej nazwanych katalogach i przy korekcie dziwnie nazywanych plików, z OpenOfficów instalowanych i przenośnych. I w każdym przypadku działało. Nie twierdzę że nie ma błędu, ale brak mi już wyobraźni, a bez odtworzenia problemu trudno myśleć o jego przyczynie. Visty w ogóle nie mam w zasięgu, a 7 chwilowo też nie.

[Jactra]

Pobrałem Twój plik jeszcze raz i .... działa !!!

Jan_J wielkie dzięki !!!! .
To mi wystarczy. Zmienić jeden akapit to już nie problem. Najważniejsze, że są polskie znaki i prawidłowy kierunek tekstu w reszcie dokumentu.

[vbert]

Witam,

Skrypt w dokumencie popraw.odt nie działa
Po kliknięciu na button Go ... nic się nie dzieje.
Dopiero z menu Narzędzia wybór opcji zarządzania makrami
pozwala dostać się do możliwości uruchomienia skryptu, ale ...
... wywala to Write, a potem odzyskiwanie dokumentu i tak w kółko.

Przy okazji, chciałbym zerknąć w źródła tego skryptu, jak to zrobić?

Mam Kubuntu 11.10, LibreOffice 3.4.5.

[Jan_J]

Kod skryptu jest zacytowany w poście wyżej, choć nie dam głowy, czy była to ostatnia wersja.
Możesz go pobrać także z dokumentu: plik odt jest zip-em; po rozpakowaniu znajdziesz skrypt w kartotece Scripts/python.

Debugowanie skryptów Pythona spod OpenOffice jest beznadziejnie żmudne. Testowałem go pod LO3.4 i OOo3.3 w Fedorze, CentOSie i Windows XP, ale nigdy na pakiecie biurowym dostarczonym razem z systemem.