Aby zachować czytelność źródła tabeli Markdown, dodawaj spacje do komórek i wyrównuj ponownie każdą kolumnę po większych zmianach. Na Macu w Obsidianie edytuj tabelę za pomocą wbudowanego edytora, a potem sprawdź ją w trybie źródłowym. Wyrównanie spacji w źródle i wyrównanie tekstu w wyrenderowanej tabeli wymagają osobnego sprawdzenia.
Ten sposób pracy jest przeznaczony dla osób, które utrzymują niewielką tabelę Markdown w notatce na komputerze: listę lektur, spis artykułów papierniczych lub listę kontrolną projektu. Celem jest zachowanie czytelności tekstu źródłowego podczas zmian wpisów, a zarazem utrzymanie działającej tabeli w docelowym rendererze.
Co sprawia, że źródło tabeli Markdown jest czytelne?
Czytelna tabela źródłowa ma wyraźne granice kolumn, spójne odstępy i jeden kompletny wiersz w każdej linii. Jej znaki pionowej kreski układają się w pionie w czcionce o stałej szerokości. Dokumentacja GitHuba wyraźnie stwierdza, że komórki nie muszą mieć jednakowej szerokości ani idealnie wyrównanych kolumn w źródle, więc takie wyrównanie ułatwia edycję, ale nie jest wymagane, aby tabela była poprawna. Porządkowanie informacji za pomocą tabel.
Na przykład ta przykładowa tabela jest zwięzła, ale trudniej ją przejrzeć po wpisaniu dłuższej nazwy elementu:
| Item | Finish | Count |
| --- | --- | ---: |
| Pencil | Matte | 4 |
| Large sketchbook | Linen | 12 |
Dodanie spacji ułatwia sprawdzanie tej samej zawartości w postaci zwykłego tekstu:
| Item | Finish | Count |
| ---------------- | ------ | ----: |
| Pencil | Matte | 4 |
| Large sketchbook | Linen | 12 |
W GFM spacje między granicami oznaczonymi kreskami a zawartością komórek są usuwane. Wypełnienie spacjami nie określa więc szerokości kolumn w wyrenderowanej tabeli. Dwukropek w ----: ustawia wyrównanie do prawej w wyrenderowanej kolumnie; spacje przed 4 jedynie ułatwiają przejrzenie tego przykładu źródła. Specyfikacja GitHub Flavored Markdown, tabele.
Traktuj te kwestie jako dwie odrębne decyzje: dobierz spacje, by ułatwić czytanie źródła, a dwukropki w wierszu separatora — by ustawić wyrównanie tekstu w wyrenderowanej tabeli. Jeśli problemem są tylko nierówne kreski w edytorze, zmiana dwukropków go nie rozwiąże.
Który renderer odczyta tabelę?
Tabele z kreskami pionowymi są rozszerzeniem, a nie funkcją podstawowego CommonMark. Aktualna specyfikacja CommonMark wskazuje wersję 0.31.2, natomiast opublikowana specyfikacja GFM GitHuba wyraźnie definiuje tabele jako rozszerzenie CommonMark. Renderer opisany wyłącznie jako zgodny z CommonMark nie gwarantuje tym samym obsługi tabel z kreskami pionowymi. Sprawdź, czy obsługuje również rozszerzenie tabel. Specyfikacja CommonMark, Specyfikacja GitHub Flavored Markdown.
Podczas przenoszenia notatki między aplikacjami mają znaczenie następujące różnice:
| Miejsce docelowe | Udokumentowane działanie | Praktyczny wybór |
|---|---|---|
| Podstawowy CommonMark | Podstawowa specyfikacja nie zawiera składni tabel z kreskami pionowymi | Sprawdź, czy dostępne jest rozszerzenie tabel |
| GitHub | Przewodnik po tabelach wymaga co najmniej trzech łączników w każdej komórce separatora | Użyj --- lub dłuższego ciągu |
| Obsidian | Przewodnik po tabelach dopuszcza minimum dwa łączniki i nie wymaga wyrównania komórek w źródle | Jeśli tabela ma być też używana na GitHubie, użyj co najmniej trzech |
Powyższe wymagania dotyczące liczby łączników pochodzą z przewodników poszczególnych produktów. Użycie co najmniej trzech to wygodna wspólna konwencja dla tych dwóch miejsc docelowych; nie oznacza, że wszystkie renderery Markdown działają tak samo. Dokumentacja tabel GitHuba, Zaawansowana składnia formatowania w Obsidianie.
W tabeli przeznaczonej zarówno do Obsidiana, jak i na GitHuba używaj początkowych i końcowych kresek pionowych, zwykłych spacji do wypełniania komórek oraz pustego wiersza przed tabelą i po niej. Przewodnik GitHuba wymaga pustego wiersza przed tabelą; specyfikacja GFM opisuje pusty wiersz jako zakończenie tabeli. Wyraźne zaznaczenie obu granic ułatwia też rozpoznanie tabeli w źródle. Dokumentacja tabel GitHuba, Granice tabel w GFM.
Jak utrzymywać tabelę w Obsidianie na Macu
Obsidian oferuje wygodny sposób edytowania komórek, po którym można uzyskać czytelny Markdown. Informacje o wydaniu desktopowej wersji 1.5.8 wspominają o automatycznym formatowaniu tabel podczas pisania, które porządkuje kolumny widoczne w trybie źródłowym. To udokumentowane działanie edytora, a nie funkcja składni Markdown. Informacje o wydaniu Obsidian 1.5.8 Desktop.
W przypadku zwykłej notatki wykonaj te czynności:
- Otwórz notatkę w trybie
Live Preview. W razie potrzeby wybierz ten tryb za pomocą ikony stanu edytora. - Wstaw tabelę poleceniem
Insert Tablealbo kliknij prawym przyciskiem myszy i wybierzInsert → Table. - Wpisz lub zmień zawartość komórek w edytorze tabel. Gdy trzeba dodać, usunąć, przenieść lub posortować wiersze i kolumny, kliknij tabelę prawym przyciskiem myszy.
- Wybierz
Source modeza pomocą ikony stanu i sprawdź wynikowy Markdown. - Przełącz się do
Reading view, aby sprawdzić wyświetloną tabelę.
Sterowanie trybami opisano w sekcji Widoki i tryb edycji; wstawianie tabel i operacje z menu kontekstowego opisano w sekcji Zaawansowana składnia formatowania.
Jeśli często przełączasz tryby, przypisz skrót klawiszowy do polecenia Toggle Live Preview/Source mode. W systemie macOS skrót Cmd+E przełącza widoki czytania i edycji; jeśli chcesz przełączać konkretnie dwa tryby edycji, użyj osobnego polecenia zmiany trybu. Widoki i tryb edycji w Obsidianie.
Jeśli bezpośrednia edycja w trybie Source mode powoduje nierówne odstępy, wróć do wbudowanego edytora tabel, wprowadź dalsze zmiany, a potem sprawdź źródło. Przywołana dokumentacja potwierdza automatyczne formatowanie tabel i możliwość dokładnego sprawdzania źródła, ale nie gwarantuje, że każda dowolna zmiana w źródle zostanie natychmiast ponownie wyrównana spacjami. W przypadku małej tabeli, w której odstępy nadal są nierówne, poniższa metoda ręczna daje bezpośrednią kontrolę.
Jak ponownie wyrównać kolumny w źródle po większej zmianie
Zastosuj prostą zasadę: każda kolumna w źródle powinna być na tyle szeroka, by pomieścić jej najdłuższy obecny wpis wraz z nagłówkiem. Dodaj spacje do pozostałych komórek w kolumnie. Przelicz szerokość, gdy wpis staje się dłuższy niż dostępne miejsce.
Oto praktyczny przykład wykorzystujący wyłącznie zwykłe znaki ASCII. Zacznij od tej tabeli:
| Item | Finish | Count |
| ------ | ------ | ----: |
| Pencil | Matte | 4 |
| Folder | Linen | 12 |
Teraz zastąp Folder tekstem Large sketchbook. Nowy wpis ma 16 znaków, więc pierwsza kolumna potrzebuje miejsca na 16 znaków treści. Pozostaw po jednej spacji bezpośrednio przy każdej granicznej kresce pionowej, a następnie dodaj tyle końcowych spacji, by wypełnić ten obszar:
Itemma 4 znaki, więc dodaj po nim 12 spacji wypełniających, a następnie spację przy granicy.Pencilma 6 znaków, więc dodaj po nim 10 spacji wypełniających, a następnie spację przy granicy.Large sketchbookwypełnia obszar 16 znaków, więc potrzebuje już tylko spacji przy granicy.- Wydłuż pierwszą komórkę separatora do 16 łączników, aby uzyskać pasujący wizualny znacznik.
Wynikiem jest wypełniona spacjami tabela pokazana wcześniej. Poszerzenia wymagała tylko pierwsza kolumna. Pozostałe kolumny zachowują odstępy i znaczniki wyrównania.
To ręczny sposób formatowania dla podanego przykładu ASCII, a nie uniwersalny algorytm obliczania szerokości znaków. Przy codziennej edycji sprawdzaj wynik w widoku źródła używającym czcionki o stałej szerokości. Jeśli komórki zawierają dużo formatowania w tekście, oceń szerokość źródła na podstawie faktycznie zapisanych znaków, w tym interpunkcji, takiej jak odwrotne apostrofy i gwiazdki.
Po serii zmian wyrównaj tabelę raz, zamiast poprawiać każdy wiersz po każdym naciśnięciu klawisza. Jeśli wpisy często stają się akapitami, rozważ pozostawienie w tabeli krótkiej etykiety i przeniesienie objaśnienia do zwykłego tekstu pod nią. Zmniejszy to ilość pracy nad odstępami bez skracania informacji.
Co sprawdzić, gdy tabela przestaje działać?
Zanim zaczniesz poprawiać odstępy, sprawdź strukturę. Zgodnie z GFM nagłówki i wiersz separatora muszą mieć taką samą liczbę komórek. Wiersz treści z za małą liczbą komórek otrzymuje puste komórki, a nadmiarowe komórki są ignorowane. Tabela może więc wyglądać poprawnie, a mimo to pomijać część treści w wyrenderowanym wyniku. Zasady parsowania tabel GFM.
Po większej zmianie wykonaj kolejno te czynności diagnostyczne:
- Porównaj wiersz nagłówka z wierszem separatora. Każdemu nagłówkowi przyporządkuj komórkę separatora.
- Sprawdź wszystkie wiersze treści. Zachowaj wymaganą liczbę komórek również wtedy, gdy któraś wartość jest pusta.
- Poszukaj dosłownych znaków kreski pionowej w treści. Niezabezpieczona kreska może zostać zinterpretowana jako kolejna granica.
- Sprawdź granice wierszy. Każdy wiersz tabeli pozostaw w jednej linii źródła i unikaj pustych wierszy wewnątrz tabeli.
- Sprawdź podgląd w miejscu docelowym. Skontroluj zarówno wyświetlane wartości, jak i wygląd tabeli.
GitHub opisuje dodawanie odwrotnego ukośnika przed dosłowną kreską pionową. Ten kompletny przykład zachowuje Blue | Green w jednej komórce:
| Item | Options |
| ------ | ------------- |
| Folder | Blue \| Green |
Ten znak ucieczki wpływa na strukturę; dodanie większej liczby spacji wokół niezabezpieczonej kreski nie rozwiąże problemu. Przykład GitHuba z dosłowną kreską pionową.
Obsidian opisuje też sposób zabezpieczenia kreski pionowej używanej w aliasie linku wewnętrznego w tabeli. Jest to kwestia składni specyficzna dla Obsidiana, więc zabezpieczony alias sam w sobie nie gwarantuje takiego samego działania linku na GitHubie. Wskazówki Obsidiana dotyczące formatowania tabel.
Nie naciskaj klawisza Enter w środku długiej komórki, aby zwęzić jej tekst źródłowy. Tabele GFM akceptują treść śródliniową i wykluczają elementy blokowe; nie zapewniają ogólnego formatu komórek z wieloma liniami źródłowymi. Jeśli jednowierszowe wiersze stają się niepraktyczne, przenieś dłuższe objaśnienia poza tabelę. Zasady dotyczące treści tabel GFM.
Ogranicz rutynową konserwację do kilku czynności: zakończ zmiany treści, sprawdź granice komórek, ponownie dodaj spacje w zmienionych kolumnach i obejrzyj wyrenderowaną tabelę. W Obsidianie praktycznym punktem wyjścia jest wbudowany edytor tabel, a następnie Source mode. Ręczne dodawanie spacji jest przydatne, gdy chcesz uzyskać określony układ zwykłego tekstu.
Źródła
- Specyfikacja CommonMark — CommonMark
- Specyfikacja GitHub Flavored Markdown — GitHub
- Porządkowanie informacji za pomocą tabel — Dokumentacja GitHuba
- Zaawansowana składnia formatowania — Pomoc Obsidiana
- Widoki i tryb edycji — Pomoc Obsidiana
- Obsidian 1.5.8 Desktop (Public) — Obsidian