Witam. Ja jak zwykle (2) z problemem do rozwiązania
Czy wie ktoś może jak zaimplementować pełną obsługę Unicode w C++ i/lub bazie danych (SQL na przykład)? Słyszałem, że wystarczy wykorzystać odpowiednią bibliotekę, a jeśli tak, to ktoś wie jaką?
Mam na myśli przechowywanie i wyświetlanie napisów we wszystkich alfabetach (nie mylcie Kanji, Katakany i Hiragany z alfabetem! Sylabariusze, logogramy i ideogramy to systemy pisma), tj. głównie w łacińskim, greckim, arabskim i cyrylicy, ze wszystkimi diakrytykami. Jeśli się da, i wiecie jak je wyświetlić, to jak się je przechowuje? Zapisywać ich kody z tablicy znaków, czy można po prostu je wpisać w oryginalnym alfabecie i bezstratnie przechowywać?
Musisz jednak wziąć pod uwagę, że nie ma czegoś takiego jak wyświetlanie we wszystkich alfabetach. Języki pisane od prawej do lewej są szalenie problematyczne w obsłudze. Mieszanie języków jest w ogóle poważnym wyzwaniem. Wystarczy sprawdzić jak z mieszaniem języków na stronie WWW radzi sobie IE, jak Opera a jak FF. Tylko IE stara się zrobić to poprawnie (i w 9 przypadkach na 10 udaje mu się).
To czy, gdzie i jak przechowywać znaki zależy od konkretnej aplikacji. Aha! C# natywnie bardzo dobrze radzi sobie z Unicode - może warto rozważyć.
IPA sugeruje pisanie Kanji. Na japonistyce na UAM (uważany za sztandarowy w Polsce, jeśli chodzi o neofilologię) też uczą jako Kanji. Na Wiki też jest napisane Kanji (wiem, wiem, to akurat żaden autorytet). Jestem skłonny twierdzić, że obie formy są poprawne, albo jedna z nich jest nowsza
Co do obsługi języków - a jakiego API sugerujesz użyć? Zrobić własne, wykorzystać biblioteki C++, czy kontrolki IE lub Gecko? Bo ja się generalnie w tym gubię, i o taką pobieżną opinię bym prosił (za studiowanie bloga się wezmę niedługo). I osobiście jeszcze nigdy nie zmusiłem chyba programu w C++ do wypisywania znaków diakrytycznych
Problem w tym, że Hanzji jest chińskim systemem pisma a nie japońskim i chińska (konkretnie Mandarin) nazwa to właśnie Hanzi. Nie dziwię się, że na japonistyce mówią Kanji, bo to japońska nazwa tego systemu. Co więcej: jeśli pracuję (a pracuję) z ludźmi z Hong Kongu, Tajwanu, Chin i Singapuru i wszyscy twierdzą, że to Hanzi, to wierzę im. Zresztą Wikipedia ma i hasło Hanzi. Nie jest to kwestia “nowości” a języka w którym system nazywasz. System jest chiński i po chińsku nazywa się Hanzi.
To w czym i jak zależy jak chcesz swoją aplikację zbudować. Podam Ci kilka przykładów.
Prosty słownik
Wpisujesz słowo - pokazuje Ci odpowiedniki w innych językach. Każda “odpowiedź” na zapytanie to może być osobny label. Nie ma potrzeby używać Tridenta czy Gecko.
Średnio zaawansowany słownik
Wpisujesz słowo - pokazuje Ci opis słowa, konktekst i pochodzenie w innych językach. Masz do czynienia z rozbudowanym tekstem. Wciąż label lub odpowiednio “oskórowany” textbox sobie poradzi.
Zaawansowany słownik
Wpisujesz słowo - pokazuje Ci opis słowa, konktekst i pochodzenie w innych językach. Masz do czynienia z rozbudowanym tekstem i niewielką liczbą linków. Kontrolka RTF da sobie radę.
Bardzo zaawansowany słownik
Wpisujesz słowo - pokazuje Ci opis słowa, konktekst i pochodzenie w innych językach. Masz do czynienia z rozbudowanym tekstem i sporą liczbą linków. Dostępna jest grafika i elementy dynamiczne. Trident lub Gecko są lepszym rozwiązaniem
Plus: jeśli potrzebujesz mieszania języków R-L i L-R nie pozostaje Ci nic innego niż Trident. Lub autorskie rozwiązanie, ale gwarantuję Ci, że nie zrobisz tego w 100% poprawnie.
Opisz dokładniej co aplikacja ma wykonywać, wyświetlać, składować, to uzyskasz bardziej konkretną odpowiedź.
Otóż aplikacja będzie najpierw wyszukiwała słowo w odpowiednim pliku indeksowania, potem, po znalezieniu go, sprawdzała dane nt. jego położenia w prawdziwej bazie. Wyświetli wszystkie słowa, które będą do niego przypisane w pośrednim języku, i wywoływało wszystkie. Będzie pokazywanie etymologii, pochodzenia, rodzaju, przypadku, odmiany, klasy, etymologii, opisu w języku natywnym, podział na sylaby, oddzielenie tematu od końcówek, zapis w IPA (i wyszukiwanie także wg. IPA), zapis słowa w oryginalnym alfabecie i alfabecie łacińskim. Języki pisane LP, PL i mieszane (mlaskowe, bantu). Do tego dochodzi jeszcze ok. 25 innych kryteriów językowych
Ambitny projekt. Masz trzy opcje, uszeregowane od najmniej ambitnej (i mającej największe szanse na powodzenie) do najbardziej ambitnej:
Trident (kontrolka ActiveX IE)
Gecko + łatki, żeby działało mieszanie języków
własne rozwiązanie
Pierwsza opcja działa z kopyta. Jeśli zdecydujesz się na opcję środkową - warto IMO okroić Gecko z czego tylko się da. Łatanie obsługi LR - RL będzie kłopotliwe, ale jak wszystko, wykonalne. W przypadku Gecko musisz też bardzo uważać na kwestie licencyjne. Wyłącznie opcje 2 i 3 pozwalają Ci na aplikację multiplatformową.
Jeśli zależy Ci na maksimum funkcjonalności w minimum czasu i minimalną ilość poprawek, postawiłbym na C# + Trident. Do magazynowania danych: pliki tekstowe lub baza danych (nie ładuj się w XML, bo dla ilości danych, które potencjalnie możesz mieć, nie sprawdzi się). Musisz też wziąć pod uwagę to, że nie każdy OS dysponuje czcionką zdolną wyświetlić np. notację fonetyczną IPA. Vista ma Arial Unicode - warto zerknąć, czy czcionka ta nie może zostać pobrana z centrum plików MS dla systemu Windows XP. Brak Arial Unicode oznacza, że aplikacja będzie miała zależności od kilku(nastu) fontów.
Co do czcionki - znalazłem Gentium, darmowa do wszystkich zastosowań, obsługuje Unicode w 100%. Co do kontrolki ActiveX… hmm, nie lubię ActiveX, i nie chcę robić kolejnego rupiecia używającego tego niewypału w kwestiach bezpieczeństwa. Co do modyfikacji Gecko - będzie trudno, zanim się nauczę, to się zdążę zestarzeć
Najmniej ambitne to C# + Trident… czemu? Będę musiał w tym przypadku z czegoś zrezygnować albo uderzyć w wydajność?
Wątpię. Unicode definiuje 100tys znaków. Nie wiem jak wygląda sprawa z innymi formatami, ale TTF ma limit znaków (65tys albo 32tys - nie pamiętam). Ja tam jestem ostrożny jeśli chodzi o absoluty.
Stare mity umierają ostatnie. :roll: Jak ktoś nie rozumie jakiejś technologii, to nie powinien jej używać. Bez względu na to jaka to technologia, skutki będą opłakane. Większość softu powstaje w stodole i jakość jest najwyżej mierna; w takiej sytuacji zawsze coś się będzie sypało. A winowajcy najlepiej szukać na cudzym podwórku.
Najmniej ambitne, bo będzie “magicznie” działało. Ja wychodzę z założenia, że aplikacja ma przede wszystkim działać stabilnie i przewidywalnie. Nie jestem zwolennikiem wynajdowania koła. Niestety jestem w mniejszości w Internecie.
Pisząc o ambicji mówiłem o ich przeroście - Twój projekt jest wystarczająco ambitny w założeniach i nie musisz (moim zdaniem) silić się na technologicznie szalenie ambitne wyzwania typu pisanie własnej kontrolki do wyświetlania złożonego, formatowanego tekstu.
Napisanie takiej aplikacji w C# z użyciem kontrolki IE pozwoli Ci szybko uzyskać wymierne efekty, które następnie możesz podkręcać (poprawiać wydajność, eksperymentować z interfejsem, zwiększać ilość ficzerów). Działający produkt uzyskasz szybciej - będziesz mógł się nim podzielić z jakąś grupą testerów (znajomych, zainteresowanych projektem - nie ważne, takich, którzy zgłoszą feedback) a tym samym będziesz mógł wcześnie zmienić lub nagiąć kierunek aplikacji (czy pojedynczego ficzera) jeśli użytkownicy zgłoszą z nim problem.
Bawiąc się we własne technologie stawiasz się w sytuacji, w której nie dość, że robisz od zera coś co istnieje (i możesz nigdy tego nie ukończyć, albo ukończysz a nie będzie lepsze niż istniejące rozwiązanie) to jeszcze dokładasz sobie problemów do już złożonego projektu.
Odpowiadając na pytanie o wydajności - tutaj kosmiczną rolę gra doświadczenie. Tak jak w C# tak i w C++ czy Javie można napisać ślimaczącą się aplikację. To nie jest tak, że język umyślnie sprawia, że aplikacja się wlecze; to niedoświadczony w danym języku programista pisze crapowaty kod, który się wlecze. Jeśli napisanie aplikacji w C# zajmie (powiedzmy) 3 miesiące a w C++ 4 miesiące, to ten miesiąc różnicy możesz przeznaczyć na tuning aplikacji. W większości wypadków uzyskasz lepszy (tutaj: zarówno szybszy jak i stabilniejszy) kod, jeśli będziesz miał dodatkowy czas na poprawki. C# jednakże nie rozwiąże magicznie problemów, które wynikają z ograniczeń programisty, więc jeśli jesteś negatywnie nastawiony do wszystkiego co pochodzi od MS (tak jak to kontrolek ActiveX) to niestety jedyne co mogę zrobić, to życzyć Ci powodzenia w utrudnianiu sobie życia.
Jeszcze drobna dygresja o hanzi: to zapis pinyin, zatem “z” czyta się mniej więcej jak polskie “dz”.
Hmm, różnica w fonetyce może wynikać z tego, że roomaji ma różne odmiany. Ja tam japońskiego się nie uczę, mi tak ludki z japonistyki rzekły i tyle. Kiedyś to zweryfikuję
Co do nastawienia na produkty MS - nie na wszystkie jestem źle nastawiony - .net framework się sprawdził jako dobre rozwiązanie. Aczkolwiek od kiedy mam wyłączone ActiveX i Java Script, to mój antywirus się nudzi
Dobra, przekonałeś mnie do użycia C# + IE (żegnaj wieloplatformówko) A co do czcionek - można zawsze wykorzystać kilka, jedną do takich znaków, inną do takich… zresztą nie mam zamiaru wcale wykorzystywać 32 tysięcy Sama tablica znaków to 1/2 czy 1/3 tego, co potrzebuję, a i tak ona sama mi jakiś czas wystarczy. Zresztą - fonty zawsze można dorobić sobie samemu
Szkoda, że na studiach mam PERL-a a nie C++, ale z braku laku… przynajmniej trochę podobny do C++, a jakby jeszcze biblioteki dorzucić…
Dzięki wielkie za wyczerpującą odpowiedź i wszelkie rady
Kontrolka IE zrobi to za Ciebie. Mnie głównie chodziło o kompatybilność - na 95/98 (i chyba XP) czcionki złożone są opcjonalnym komponentem. Testowanie aplikacji to mniej więcej połowa procesu jego tworzenia (chyba, że chcesz stworzyć kolejną aplikację, która działa tylko na komputerze autora i jego dwóch kolegów ). Testowanie upraszcza się, jeśli masz mniej zależności. Istnienie pewnych czcionek w systemie jest zależnością i powinno zostać przetestowane (szczególnie w Twojej aplikacji - w końcu o tekst w niej głównie chodzi).
Powodzenia. :? Po pierwsze ogranicza Cię licencja fontu, na którym się wzorujesz, po drugie musisz to zrobić tak, żeby po prostu działało (bez przekodowywania w locie czy interpretacji tekstu, “bo są w nim wyjątkowe znaki”).
