Який правильний персонаж для апострофа?

Багато разів я стикаюся з так званим " машинописним апострофом " (символом Unicode U+0027та символом HTML '), щоб представити апостроф:

Але з іншого боку, замість цього використовується також " правильний єдиний лапки " (символ Unicode U+2019та HTML-символ ’):

Цікаво зараз, хто з них є правильним і його слід використовувати в типографії?

^{Примітка: шрифт sans-serif Arial використовувався в обох прикладах.}

Почалося зігнуто

Апостроф вперше з'явився у друкованому Всесвіті в Італії, 16 століття, як вигнута форма для позначення елізіона, скопійованого з рукописної класичної італійської поезії. Апостроф був еквівалентний нашим "Готчасам" або "Ваннам" в тому сенсі, що це був спосіб зняти жорсткість тексту, зробивши його звучанням більш людським.

Ось приклад одного з перших разів друку апострофа. Саме з «Le Cose volgari ді мессер Франческо» італійський класик написав Петрарки, опублікований Альдо Мануций в Італії близько 1501 року .

Альд Манутій нібито скопіював цю книгу з оригінального рукопису Петрарки, що належить його другові. Він мав спеціальний шрифт, розроблений на основі почерку поета, створюючи похилий стиль, який ми сьогодні знаємо як «курсив». Йому довелося ввести гліф апострофа, щоб можна було скопіювати текст саме так, як його написав поет. Зауважте апостроф у слові (слова) "l'honorata". Зауважте, він мав вигнуту форму.

Це стало модним

Цей інноваційний "курсивний" тип та розмовно-стильний спосіб позначення елісій як милого маленького знака здобули негайну популярність. Навіть тоді, коли шрифт був захищений самим Папою, його почали незаконно копіювати підроблені художники. Примірники книги були надруковані в Ліоні, використовуючи піратську копію шрифта з апострофом і все.

У 1501 році Джеффруа Торі видав Кампофлорі, книгу, яка здійснила революцію у французькій граматиці та книговиданні. Він ввів, серед іншого, апостроф, копіюючи новий модний італійський спосіб вважати елісії стильними. Це уривок із книги. Зауважте зігнутий апостроф.

У тому ж столітті і з тих же причин англійська мова імпортувала апостроф з французької.

Це дісталося прямо

Апостроф перестав бути новинкою і став частиною звичайної граматики. Він зберігав свою вигнуту форму в друкованих текстах. Прямий апостроф-подібний гліф, з іншого боку, мав різні функції, наприклад, позначати "простим". Однак у документах, написаних від руки, іноді вони були стилізовані як прямий галочок (див. Коментар Йорка нижче).

З винаходом машинок і клавіатур (1860-х років) інженери зіткнулися з проблемою розміщення багатьох символів (клавіш) на невеликому просторі. Вони придумали ідею об'єднати схожих на вигляд персонажів, щоб заощадити місце. Замість того, щоб мати ліві, праві та прямі «апострофи», вони вирішили включити лише прямий. Подібні рішення приймалися щодо інших символів, поширених у наборі тексту, таких як em dash та en dash.

https://en.wikipedia.org/wiki/Typewriter#Typewriter_conventions

Цей зменшений набір символів був кодифікований у першому у світі наборі двійкових символів, 5-бітовому коді Бодо (1870). Набір також включав пряму подвійну цитату як єдиний символ. 7-бітний ASCII успадкував той же набір символів.

З того часу весь набраний (і телеграфний) текст встановлювався за допомогою лише прямих лапок. Фігурні використовувались лише у традиційному наборі тексту.

Вийшло неоднозначно

Лише з популяризацією текстових процесорних систем кучеряві апострофи були знову введені в цифровий світ. Такі системи, як Word, пропонували функцію автоматичної заміни прямого апострофа фігурними лапками на основі контексту. Користувач може зробити це, хоча, і не всі текстові процесори мали цю особливість. Для додавання плутанини, стандартні клавіатури не містили фігурних лапок, тому звичайному користувачеві було дуже важко вводити їх навмисно.

Коли було створено Unicode, одним із принципів проектування було "уніфікація" символів. Персонажі з різних сценаріїв або мов, схожих на них, мали бути уніфіковані та спрощені як окремі. Ви могли б подумати, що вони повернулися б до походження і позбулися б прямого апострофа. Тепер, до цього моменту, плутанина і ліберальне використання прямих і фігурних апострофів і лапок було настільки великим, що Unicode вирішив включити і те, і інше.

Апостроф сьогодні

Отже, як сьогодні, і обидва (фігурний і прямий апостроф) приймаються як апостроф та лапки, але є деякі міркування:

• Якщо намір тексту полягає в тому, щоб він виглядав так, ніби він був традиційно набраний, то завжди використовуйте фігурні, як це було спочатку. Тримайте пряму для позначення простих.

• Використання прямого апострофа та цитати може бути способом наведення цифрового настрою на ваш документ, однаково символи однакової ширини означають, що текст був набраний на машинці або консолі.

• Якщо текст цифровий і споживається людськими очима, обидва (фігурний і прямий апостроф) приймаються як апостроф і лапки. Тут школи відрізняються і правилами розколу. Ми продовжуємо виразний безлад. Просто будьте послідовними в одному документі.

• Якщо намір тексту має бути семантично правильним (як би ви хочете, щоб комп'ютер міг розбирати семантику тексту), тоді вам слід приділити пильну увагу визначенню символів Unicode. U + 0027(той, який можна набрати за допомогою клавіатури) називається "APOSTROPHE". Хоча це натякає на те, що може бути хорошим кандидатом представляти апострофи, зауважте, що Unicode є своєрідними двозначностями щодо цього персонажа, що вказує на те, що принаймні англійською мовою U + 2019 є кращим для апострофів. Я особисто думаю, що це суперечить їх принципу об'єднання. Ви б очікували, що апостроф буде однаковим незалежно від мови, якою він використовується. Додайте до цього той факт, що вони класифікують апостроф як "пунктуацію", яка французькою мовою може бути незграбно прийнята, але англійською мовою не має сенсу. Тоді у вас залишається загроза або використовувати різні апострофи для різних мов, або використовувати спірну для англійської мови. Обговоренняпро те, який з них є правильним, можна отримати дуже пристрасть. З іншого боку, видається цілком зрозумілим, що U + 2019 (і ніколи не прямий) слід використовувати як правильну лапку. Тим же символом U + 2032 слід використовувати для позначення простих, а U + 02BC слід використовувати для позначення апострофа літери модифікатора (наприклад, в глоттальній зупинці вимови Кокні букера або транскрипції "uh'oh" ").

• Зауважте, що навіть якщо ви обрали або ввели правильний символ, використовуваний шрифт може зробити його фігурним або прямим.

Зробив трохи досліджень, щоб переконатися, але загалом "належна" типографія не використовує прямих лапок, одинарних чи подвійних. Ось зручний посібник для команд та HTML-об'єктів для одиночних / подвійних фігурних лапок .

Друкарські машинки також несуть відповідальність за введення «прямих лапок», неспецифічних цитатних знаків, розроблених як мірку економії місця для клавіатури, уникаючи необхідності окремих розкриття та закриття лапок. Прямі котирування зазвичай використовуються замість належних лапок або "фігурних лапок". Багато дизайнерів скажуть вам, що прямі цитати використовуються для зображення ніг і дюймів, але насправді стопи та дюйми повинні бути представлені за допомогою прайметів. Прямі цитати застарілі, і їх не слід використовувати.

З друкарської грамотності: друга частина (KA + A)

Коментар Unicode Standard щодо U + 2019 (') :

це кращий символ, який слід використовувати для апострофа

Щодо правильного кодування, я не можу придумати вищий авторитет.

Також типографічні конвенції більшості мов не використовують U + 2019 для інших цілей або лише як вторинні лапки. Насправді англійська англійська мова є єдиною основною мовою, яка використовує цей символ як основний лапок. Таким чином, для розрізнення тут немає великої потреби використовувати U + 0027 (або будь-який інший символ).

Типографічно існує три підходи до визначення того, що є «правильним»:

1. До чого звикли люди - Хоча в класичному та професійному наборі людей в основному піддаються фігурному апострофу, апостроф друкарської машинки домінує над цифровими текстами. Тут немає хорошої відповіді.

2. Що відповідає загальному характеру шрифту без істотного перешкоджання читанню - Це дещо залежить від шрифту. Давайте розглянемо кілька прикладів:

   

   У всіх прикладах апостроф в " Не є U + 2019", а апостроф в " не" - це U + 0027. Спочатку зауважте, як обидва символи відрізняються між шрифтами.

   • Перший приклад - легкий шрифт sans-serif. Це далеко не орнамент, і кучерявий апостроф був би не на місці. Отже, U + 2019 лише трохи нахилений. Прямий U + 0027 також цілком відповідає простому символу шрифту.

   • Круглі форми, очевидно, є основною парадигмою шрифту у другому прикладі. Отже, U + 2019 кучерявий. U + 0027 призначений для уникнення будь-якого почуття напрямку (імовірно, він також може бути використаний як початковий знак лапки) і, отже, кривих. Крім того, вона є досить невеликою, імовірно, компромісом між униканням порушити характер шрифту з великим символом і перешкоджати читанні з крихітним символом. Якщо ви запитаєте мене, компроміс занадто крихітний, але це лише симптом - актуальною проблемою є компроміс, якого можна уникнути, використовуючи фігурний апостроф, який набагато краще підходить до шрифту.

   • У класичних шрифтах серії, як у третьому прикладі, ширина штриха в основному залежить від кута (який бере початок у каліграфії). Прямі вертикальні лінії зазвичай закінчуються серифами. Це не варіант для апострофа, і тому U + 0027 використовує форму, подібну до крапель, і таким чином порушує характер шрифту (на мою думку). Справді, те саме стосується і знаків оклику, але принаймні цей символ все одно заважатиме. Кучеряве U + 2019 набагато краще підходить до характеру шрифту.

   • Останній шрифт є ще більш каліграфічним, але його характер пропонує інший спосіб проектування суто вертикальних елементів. Таким чином, U + 0027 не так тривожно і відрізняється не так сильно, як U + 2019.

   Підсумовуючи це: Це залежить від шрифту, але правильно розроблений U + 2019 ніколи не повинен бути гіршим за U + 0027, навіть якщо останній добре розроблений. Це мало дивно, тому що дизайнер типів є більш гнучким для формування U + 2019, щоб відповідати решті шрифтів, оскільки не потрібно симетрії.

3. Що найкраще для читабельності в довгостроковій перспективі - Використання одного і того ж символу для багатьох цілей, мабуть, не добре для читабельності. Таким чином, якщо вважати, що англійські конвенції про набір тексту не змінюються інакше, прямий апостроф має перевагу в тому, що він відрізняється від фігурного закриваючого лапки. Однак цю конвенцію (використовувати U + 0027 для апострофа та U + 2019 для єдиного кінцевого лапки) встановити ще складніше, ніж встановити використання фігурних лапок та апострофів у цифровому світі.

   У багатьох інших мовах це мало б сенсу, оскільки U + 2019 так і не використовується як лапка. У таких мовах, як німецька, які використовують перевернутий U + 2018 (', англійський єдиний лапок відкриття) в якості лапки, що має два протилежні завитки або нахили (залежно від шрифту), часто сприяє кращому розрізненню - принаймні, на мою думку .

По-перше, якась історія .

Кучеряві цитати та апострофи були оригінальним стилем. Їх також називають цитатами та апострофами принтера .

Прямі цитати та апострофи прийшли разом із машинкою. Машинка, що є механічним пристроєм з обмеженнями, вирішила, що має більше сенсу використовувати один набір прямих знаків замість двох окремих наборів фігурних знаків (для відкритих і закритих одинарних та подвійних лапок).

Щоб додати ще плутанину, Праймс - це також персонаж, схожий на кут прямого апострофа. Прайми використовуються для позначення хвилин / секунди (а також інших наукових, математичних та музичних позначень). Знову ж таки, прямі апострофи друкарської машини також могли бути використані для цього.

Все, що сказано, деякі шрифти розроблені лише з прямими апострофами та цитатами з стилістичних причин.

Підсумовуючи це: завжди використовуйте фігурну версію для фактичних позначок цитат і апострофа, якщо ви не: a) використовуючи машинку з 1954 року або б) у вас є стилістичні причини використання прямого

Є один пункт, про який всі відповіді досі не згадували. У інтерфейсі командного рядка або на мові програмування апостроф (символ 27 UTF-8) є єдиним правильним вибором.

Використання U + 2019 з помилками синтаксису при вирізанні та вставці. Автоматичний переклад символу 27 на U + 2019 тепер означає, що копіювання командних рядків з документів Word (або деяких Вікі-сторінок / веб-сторінок) призведе до помилок, які змусять багатьох людей плутатись, поки ця проблема не буде вказана. Це також може спричинити помилки компілятора / інтерпретатора, які не мають сенсу.

Писаючи технічні документи з зразками коду та / або командного рядка, будьте обережні, щоб усі створені зразки використовували символ 27, а не вищий значення.

Я працюю в науково-дослідному центрі, і ми зазвичай використовуємо досить великі французькі та німецькі корпорації (досить недавні). У французькому корпусі прямий апостроф "з'являється приблизно в 4 рази більше від кількості фігурного апострофа". У німецькій мові можна знайти прямий "неіснуючий, і лише кучерявий". Різниця у французькому корпусі насправді може бути наслідком того, що прямий текст "звичайно використовується у друкованих текстах, а кучерявий" - здебільшого з текстів копіювання / вставки, які розміщуються в Інтернеті. З іншого боку, здається, німецькі джерела використовують виключно кучеряве '. Потрібно також зауважити, що апостроф набагато частіше зустрічається у французькій мові, ніж у німецькій.

Правильним символом, який слід опублікувати в опублікованому тексті як апостроф, є символ UTF-8 U + 2019 , правильна єдина цитата. Це єдиний персонаж, який дасть вам бажаний результат - апостроф книжкового рівня. Коли ви використовуєте інструмент для запису, який робить "розумні котирування", і ви натискаєте клавішу апострофа, інструмент вставить символ UTF-8 2019.

Апостроф літер U + 02BC з модифікатором UTF-8 - це крихітний апостроф для вимови. Це не буде правильно виглядати в контексті написання "не можу".

Апостроф символу UTF-8 U + 0027 - це "апостроф програміста". Залишився з зорі обчислень, коли комп'ютери мали лише 127 символів і були розроблені для написання комп'ютерних програм, не створюючи типографію на рівні книг. Перші 127 символів UTF-8 - це ті самі оригінальні 127 символів, а клавіатура комп'ютера по суті є незмінною, тому ця погана типографія живе і знову, і знову.

Причина, по якій ця помилка живе, полягає в тому, що люди, які походять з комп'ютерної спадщини, не обов'язково бачать програмові апострофи як помилки. Люди, які походять з видавничої спадщини, так і роблять. Але саме комп'ютери проектують комп'ютери. Це не є приводом для того, що в опублікованому тексті не використовується правильна типографія. Сьогодні у нас є підміна тексту, у нас є багато способів.

В ідеалі, письменникам слід користуватися інструментами, які не дозволяють їм набирати апострофи програміста, оскільки вони просто вкладають помилку в свій рукопис UTF-8. Звичайно, редактори виправлять це, але ставлення до виправлення пізніше призводить до публікації помилок.

Отже, якщо у вас є будь-який рукопис - книга, новела, стаття - і в ньому є апострофи програміста, перед публікацією слід замінити їх символом UTF-8 2019.

Те саме стосується і пропозицій програміста. Хороші інструменти для письма не повинні дозволяти письменнику їх набирати, вони повинні вводити відповідні лапки, тим більше, що їх важче виправити під час редагування та призвести до ще гіршої читабельності, якщо вони не зафіксовані, порівняно з апострофами.

Як приклад інструмента для написання, ви можете подивитися на BBEdit, який є текстовим редактором, який десятиліттями працює на Mac. Якщо ви створите документ програмування (HTML або іншу мову) і натисніть клавішу апострофа, ви отримаєте апостроф програміста. Якщо ви створите документ для написання (звичайний текст або Markdown) і натисніть клавішу апострофа, ви отримаєте символ UTF-8 2019. Те саме стосується лапок. У програмових документах ви отримуєте цитати програміста. Під час написання документів ви отримуєте справжні лапки, як початкові, так і закривальні пропозиції під час введення. Це найкращий спосіб поставити лапки, оскільки інструмент може робити належну відкриту та закриту цитату, як пише автор. Ніяка двозначність тут не вкладається в першу чергу, тому вона повинна бути виправлена ​​пізніше (чи ні.)