Jaka jest praktyczna różnica między „glifem” a „postacią”?


26

Widziałem to pytanie w propozycji witryny Typografia i denerwowało mnie to, że nie znałem odpowiedzi. Zawsze traktowałem „glif” i „charakter” jako wymienne.


Po przeczytaniu objaśnienia na stronie Model kodowania znaków Unicode rozumiem mniej więcej to:

  • Znaki są definiowane przez ich znaczenie w języku, glify, przez ich wygląd . Ligatura do estetycznego łączenia fi to jeden glif, ale dwie postacie.

Uważam więc (popraw mnie, jeśli się mylę), że praktyczną różnicą byłoby:

  • Parsery tekstu, które nie są zainteresowane estetyką tekstu, będą odczytywać glify jako ich odpowiednie znaki. Więc:
    • Jeśli skopiujesz i wkleisz tekst zawierający glify do zwykłego edytora tekstowego, glify zostaną przekonwertowane na odpowiadające im znaki ( glif ligatury stałby się fi i)
    • Każdy dobrze wykonany zautomatyzowany system oparty na analizie tekstu (np. Wyszukiwarki, czytniki ekranu, sprawdzanie pisowni) interpretowałby glify jako ich odpowiednie znaki.
    • Jedna postać może mieć wiele glifów lub zestawów glifów. Chcę powiedzieć, że jeden glif może mieć tylko jedną postać, ale to wyraźnie nie jest słuszne, ponieważ istnieje przykład na linkowanym artykule 3 glifów i zestawów glifów, które wydają się odpowiadać każdemu znakowi i zestawowi znaków. Nie do końca rozumiem, jak to może działać: z pewnością oznacza to, że w interpretacji tych glifów będą występować niespójności lub dwuznaczności, które różnią się w zależności od tłumacza? (czy różni się w zależności od języka lub czcionki?)
    • Podczas gdy przeglądarki glifów (np. Ta w programie Illustrator) zawierają pełny zestaw glifów czcionki, mapy znaków (np. Mapa znaków Windows) zawierają tylko znaki, a nie glify, które są wieloma znakami jak ligatury (czego wcześniej nie zauważyłem)

Czuję się, jakby już tam byłam, ale najwyraźniej coś źle zrozumiałem gdzieś wzdłuż linii: nie tylko „Jedna postać wielu glifów”, ale także kopiowanie i wklejanie zachowania przy użyciu ligatur nie jest tym, czego się spodziewałem:

  • Skopiuj ligaturę z programu Illustrator do tego pola wprowadzania: wklej jako fi(dwa znaki) zgodnie z oczekiwaniami.
  • Wklej dla niego kod HTML ( fi) - wyświetla się jako ligatura, gdy nie znajduje się w bloku kodu (fi - która w tej czcionce nie przypomina ligatury, ale zobaczysz, że jest jedna, jeśli spróbujesz wybrać tylko połowę tego) oraz kod, gdy jest w bloku kodu ( fi), zgodnie z oczekiwaniami.
  • Skopiuj i wklej renderowaną ligaturę bez kodu z powrotem do pola wprowadzania: wkleja się jako znak ligatury i renderuje jako ligatura niezależnie od tego, czy jest w bloku kodu, czy nie (fi i ). Podobnie zawierające je słowa: fi t mis fi ts ( fit misfits) wkleja się jak fi t mis fi ts ( fit misfits). Może zależy to od tego, czy miejsce, w którym jest wklejany, rozumie zastosowane kodowanie?

Jak bardzo błędne jest moje rozumienie tego? Czy ktoś może mnie poprawić: podając jasną definicję różnicy między glifami a postaciami (jeśli moja jest niepoprawna lub można ją poprawić) i podać jaśniejsze / dokładniejsze przykłady niż moje, co to oznacza w praktyce ?


2
To staje się znacznie bardziej skomplikowane, gdy masz skrypty takie jak arabski, w których łączysz znaki.
Przywróć Monikę - M. Schröder,

1
@ MartinSchröder +1 Brzmi jak zdanie otwierające doskonałej odpowiedzi ... :)
user56reinstatemonica8

Odpowiedzi:


4

Glify odnoszą się do sposobu renderowania tekstu, a znaki do jego interpretacji. Podczas kopiowania i wklejania aplikacja źródłowa zazwyczaj daje wybór kilku formatów. Zwykły tekst rozpadnie ligaturę na f i i, format HTML może przetłumaczyć ją na cytowaną przez ciebie postać char lub też rozłożyć na f i i.

Ogólnie relacja między znakami a glifami wynosi n: m. W językach indyjskich niektóre znaki dzielą się na dwa glify, które są umieszczone w różnych miejscach słowa. W języku łacińskim najbliżej tej sytuacji byłoby renderowanie é jako dwóch glifów (e i ´). W języku arabskim każda postać ma różne glify w zależności od pozycji w słowie: początkowa, środkowa, końcowa lub izolowana.

Tłumaczenie znaków na glify jest specyficzne dla każdej aplikacji i obsługiwanych przez nią funkcji typograficznych. W przypadku tekstu łacińskiego tłumaczenie było proste, ale czcionki OpenType wprowadziły dodatkowe funkcje, takie jak ligatury, kreski, formy alternatywne, małe litery itp.

Ze względów praktycznych zajmujesz się glifami tylko wtedy, gdy implementujesz sposób, w jaki aplikacja renderuje tekst, projektując czcionkę lub gdy chcesz zastosować funkcję OpenType, która zastępuje niektóre glify innymi (np. Ligatury). W przeciwnym razie punkty kodu Unicode są twoim przyjacielem.


Witaj user322483, witaj w GDSE i dziękuję za odpowiedź. Jeśli masz jakieś pytania, odwiedź centrum pomocy lub ping z jednym z nas na czacie z grafiką, gdy Twoja reputacja będzie wystarczająca (20). Kontynuuj wkład i ciesz się stroną!
Vincent

1
Piszecie: „W języku arabskim każdy znak ma różne glify w zależności od pozycji w słowie: początkowy, środkowy, końcowy lub izolowany”. <--- Czy nie byłyby to różne postacie. Angielski ma A i a, ale w rozmowie komputerowej A i a to różne znaki. każdy glif jest odwzorowany na inny kod. Hebrajski ma chaf i fin chaf (litera chaf na końcu słowa, wygląda inaczej) i jestem pewien, że jest określana jako inna postać w informatyce.
barlop

14

Nie sądzę, że twoje zrozumienie jest niepoprawne, po prostu widzisz systemy, które próbują pomóc użytkownikowi, wklejając to, co według niego chce. Ponieważ niektóre ligatury („fi”, „fl”) są dość powszechne poza systemami składu, oprogramowanie rozpoznaje, że użytkownik prawdopodobnie nie wprowadził tego glifu, a raczej inna aplikacja przekształciła wpisane znaki.

W skrócie: Znak odnosi się do jednostki językowej. Glif odnosi się do zaprojektowanego wystąpienia tej jednostki, niezależnie od tego, czy jest to wielka, mała litera, mała czapka, wariant historyczny czy stylistyczny.


W informatyce A i a są różnymi znakami. ASCII ma 128 znaków, a termin znak zawiera A i jako odrębne znaki.
barlop

Inżynierowie używają wielu słów, które nie pasują do precedensów w innych branżach. Twój jest dobrym przykładem.
prostokąty

kto jako pierwszy wymyślił pojęcia „charakter” i „glif”? graficy czy inżynierowie komputerowi? myślałem, że komputery pojawiły się przed projektem graficznym. Ale może istnieć branża poligraficzna, która poprzedza projektowanie graficzne i prawdopodobnie w pewnym sensie poprzedza komputery lub wyprzedza współczesne komputery. Myślę, że ludzie, którzy mogliby odpowiedzieć najlepiej na to, co jest teraz grafiką, to przemysł poligraficzny, ale nie ma wymiany stosów branży poligraficznej. Interesujące byłoby jednak wiedzieć, kto pożyczył od kogo iw jaki sposób jest to termin Postać.
barlop

1
Typografia pojawiła się na długo przed inżynierią oprogramowania. Proszę pisać tutaj, jeśli podejmiesz badania i znajdziesz pochodzenie. Domyślam się, że będzie to kiedyś w XVII wieku. Być może już w pierwszej połowie typografów w połowie 16.
prostokąty

6

Jest tu kilka odpowiedzi, które dają dobre informacje o glifach w porównaniu z postaciami, ale tak naprawdę nie dotyczą źródła twojego pomieszania w odniesieniu do kopiowania i wklejania.

Po pierwsze, twoje zrozumienie jest zasadniczo poprawne:

Znaki są definiowane przez ich znaczenie w języku, glify, przez ich wygląd . Ligatura do estetycznego łączenia fi to jeden glif, ale dwa znaki.

Warto podkreślić, że lista znaków jest zdefiniowana przez standard Unicode, który jest publikowany przez konsorcjum Unicode, ponieważ mają one uprawnienia do kodowania tekstu w formacie odczytywalnym maszynowo. Powyższa definicja jest zasadniczo podstawową wytyczną, której członkowie konsorcjum Unicode używają do ustalenia, czy jakiś proponowany dodatek do Unicode jest postacią, a zatem wartym włączenia, lub glifem i powinien być obsługiwany przez renderery czcionek.

Wspominam o tym, ponieważ zamieszanie, którego doświadczyłeś powyżej, było spowodowane faktem, że w Unicode istnieje kilka znaków ligatur (nie glifów ). Na przykład U+FB01jest to znak dla fi latury: http://unicode.org/charts/PDF/UFB00.pdf

Posiadanie ligatur znaków w Unicode nie jest tak naprawdę zgodne z powyższą definicją tego, jakie rzeczy powinny być zawarte w standardzie Unicode jako znaki, ponieważ ligatury tak naprawdę nie mają znaczenia niezależnego od składu dwóch innych znaków. Ludzie Unicode są tego świadomi, a FAQ Unicode na temat ligatur przyznaje:

Istniejące ligatury istnieją zasadniczo w celu zapewnienia zgodności i przełączania w obie strony z zestawami znaków innymi niż Unicode. Ich stosowanie jest odradzane.

Istnienie tej postaci jest ostatecznie źródłem twojego zamieszania.

W prawidłowo wdrożonego oprogramowania, kopiując tekst powinien zawsze skopiować znaki , które zostały określone, a nie znaki , i to jest dokładnie to, co dzieje się w swoich trzech przykładach.

1) W pierwszym przykładzie wpisałeś fi iw programie Illustrator, który renderował pojedynczy glif ligatury . Po wybraniu i skopiowaniu renderowanego glifu program Illustrator poprawnie skopiował znaki f( U+0066) i i( U+0069) do schowka.

2) W drugim przykładzie wpisałeś kod HTML znaku ligatury ( &#64257) w polu wejściowym i poprawnie otrzymałeś glif ligatury reprezentujący znak ligatury (. Ponieważ podstawowym znakiem jest właściwie niejasny i stosunkowo bezcelowy znak ligatury, o którym wspomniałem powyżej zaznaczenie tego glifu spowoduje skopiowanie pojedynczego znaku U+FB01.

3) W trzecim przykładzie kopiujesz renderowany znak ligatury, U+FB01który został renderowany w części 2, który zawsze będzie wklejany jako ten znak. Główne zamieszanie wydaje się dotyczyć różnicy między kodami encji HTML a znakami, szczególnie w odniesieniu do sposobu ich renderowania w blokach kodu i poza nimi.

Kod encji HTML &#64257;to ciąg 8 różnych znaków. Mechanizm renderujący HTML swojej przeglądarki zastępuje te 8 znaków U+0026 U+0023 U+0036 U+0032 U+0035 U+0037 U+0023z pojedynczego znaku Unicode U+FB01, co czyni go następnie odpowiednio. Jednak <code>znacznik w HTML wyłącza to zachowanie, pozostawiając te 8 znaków takimi, jakie są.

Podczas kopiowania renderowanego HTML kopiowane są renderowane znaki (które różnią się od renderowanych glifów ). Dlatego podczas kopiowania renderowanej encji HTML pojedynczy U+FB01znak jest kopiowany do schowka.

Po wklejeniu U+FB01znaku z powrotem do HTML nie ma potrzeby zastępowania, co oznacza, że ​​znak jest renderowany jako ligatura, niezależnie od tego, czy mieści się w <code>bloku.


1

Znaki są tym, co przechowywane w plikach tekstowych, przetwarzane przez aplikacje i przenoszone, podczas gdy glify są ich wizualną reprezentacją.

Aby uzyskać wyraźny obraz, zobaczmy, co się stanie, gdy aplikacja spróbuje wyrenderować ciąg tekstu na ekranie (w nieco uproszczony sposób):

  • Aplikacja najpierw odczytuje ciąg tekstowy, czyli ciąg znaków przechowywany na dysku lub w pamięci.
  • Następnie wysłałby go do silnika układu tekstu, między innymi właściwościami, takimi jak pożądana czcionka, język tekstu i tak dalej:
    • Mechanizm układu tekstu w zasadzie otwiera plik czcionek, prosi go o glif (y) odpowiadające każdemu znakowi i wykonuje pewne zastępowanie glifów (jak zamienianie glifu na fi ina glif ligatury fi) oraz pozycjonowanie (jak kerning).
    • Na końcu silnik układu ma sekwencję glifów, ich pozycje względem siebie oraz mapowanie między znakami wejściowymi i glifami wyjściowymi. Odwzorowanie znaku na glif polega na tym, że wie, że pierwsze dwa znaki w tym słowie fileodpowiadają dwóm pierwszemu glifowi ( filigatura), trzeciemu znakowi do drugiego glifu i czwartemu znakowi do trzeciego glifu.
  • Biblioteka renderowania grafiki jest następnie używana do „rysowania” tych glifów na ekranie za pomocą kształtów z czcionki.
  • Gdy użytkownik wybierze „glify” na ekranie, aplikacja skonsultuje się z glifem na mapowanie tekstu udostępnione przez silnik układu, aby ustalić, która część tekstu wejściowego odpowiada wybranemu przez użytkownika tekstowi i wyśle ​​ten tekst do schowka, gdy użytkownik kopiuje to.
  • To samo dzieje się, gdy użytkownik wstawi kursor w środku tekstu i zacznie pisać, mapowanie określa, gdzie w tekście wejściowym należy wstawić nowe znaki, a tekst aktualizacyjny jest wysyłany do silnika układu w celu przetworzenia i przerysowania itd.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.