Markdown tablo kaynağını okunabilir tutmak için hücreleri boşluklarla doldurun ve uzun düzenlemelerden sonra her sütunu yeniden hizalayın. Mac’te Obsidian kullanırken yerleşik tablo düzenleyicisiyle düzenleme yapın, ardından Kaynak modunu inceleyin. Kaynaktaki boşluk dolgusu ile oluşturulan metnin hizalamasını ayrı ayrı kontrol etmek gerekir.

Bu iş akışı, masaüstü notunda küçük bir Markdown tablosunu sürdürenler içindir: okuma listesi, kırtasiye envanteri veya proje kontrol listesi gibi. Amaç, girdiler değiştikçe metnin kendisini kolayca taranabilir tutarken hedeflenen görüntüleyicide çalışan bir tabloyu korumaktır.

Markdown tablo kaynağını okunabilir kılan nedir?

Okunabilir bir kaynak tablo; belirgin sütun sınırlarına, tutarlı boşluklara ve her satır için tek bir satıra sahiptir. Sabit genişlikli bir yazı tipinde görüntülendiğinde dikey çizgileri hizalanır. GitHub belgeleri, hücre genişliklerinin eşleşmesinin veya kaynak sütunların kusursuz hizalanmasının gerekmediğini açıkça belirtir. Dolayısıyla bu hizalama, geçerli bir tablo için gereklilik değil, düzenleme kolaylığıdır. Tablolarla bilgileri düzenleme.

Örneğin, bu yapay tablo kısadır ancak daha uzun bir öğe adı girildikten sonra taranması zorlaşır:

| Item | Finish | Count |
| --- | --- | ---: |
| Pencil | Matte | 4 |
| Large sketchbook | Linen | 12 |

Boşluk eklemek, aynı içeriği düz metin olarak incelemeyi kolaylaştırır:

| Item             | Finish | Count |
| ---------------- | ------ | ----: |
| Pencil           | Matte  |     4 |
| Large sketchbook | Linen  |    12 |

GFM’de boru sınırları ile hücre içeriği arasındaki boşluklar kırpılır. Bu nedenle dolgu, oluşturulan sütunun genişliğini belirlemez. ----: içindeki iki nokta, oluşturulan sütunun sağa hizalanmasını sağlar; 4 öncesindeki boşluklar ise yalnızca bu kaynak örneğinin taranmasını kolaylaştırır. GitHub Flavored Markdown Spec, Tables.

Bunları iki ayrı karar olarak değerlendirin: kaynağı okumak için dolgu seçin, oluşturulan metni hizalamak için ayırıcı satırdaki iki noktaları kullanın. Tek sorununuz düzenleyicide boruların eşit olmamasıysa, iki noktaları değiştirmek bunu çözmez.

Tabloyu hangi görüntüleyici okuyacak?

Boru tabloları, temel CommonMark’in bir özelliği değil, bir uzantısıdır. Güncel CommonMark spesifikasyonu 0.31.2 sürümüdür; GitHub’ın yayımladığı GFM spesifikasyonu ise tabloları CommonMark’e bir uzantı olarak açıkça tanımlar. Yalnızca CommonMark uyumlu olduğu belirtilen bir görüntüleyici, bu nedenle boru tablolarını destekleyeceğini garanti etmez. Tablo uzantısını da destekleyip desteklemediğini kontrol edin. CommonMark Spec, GitHub Flavored Markdown Spec.

Bir notu uygulamalar arasında taşırken şu ayrımlar önemlidir:

Hedef Belgelenen davranış Uygun tercih
Temel CommonMark Temel spesifikasyonda boru tablosu söz dizimi yoktur Bir tablo uzantısının kullanılabildiğini doğrulayın
GitHub Tablo kılavuzu, ayırıcı hücre başına en az üç tire gerektirir --- veya daha uzununu kullanın
Obsidian Tablo kılavuzu en az iki tireyi kabul eder ve kaynak hücrelerin hizalanmasını gerektirmez GitHub’ı da hedefliyorsanız üç veya daha fazlasını kullanın

Yukarıdaki tire gereksinimleri ilgili ürün kılavuzlarına dayanır. En az üç tire kullanmak, bu iki hedef için kullanışlı ve ortak bir kuraldır; her Markdown görüntüleyicisinin eşdeğer olduğu anlamına gelmez. GitHub tablo belgeleri, Obsidian gelişmiş biçimlendirme söz dizimi.

Hem Obsidian hem de GitHub için tasarlanan bir tabloda başta ve sonda boru işaretleri, dolgu için normal boşluklar ve tablonun öncesinde ve sonrasında boş bir satır kullanın. GitHub kılavuzu önce boş bir satır bırakılmasını ister; GFM spesifikasyonu ise boş bir satırın tabloyu bitirdiğini belirtir. Her iki sınırı da açıkça korumak, kaynağın tanınmasını da kolaylaştırır. GitHub tablo belgeleri, GFM tablo sınırları.

Mac’te Obsidian’da tablo nasıl korunur?

Obsidian, kolay hücre düzenlemesi yapıp sonrasında okunabilir Markdown görmek isteyenler için kullanışlı bir yol sunar. Masaüstü 1.5.8 sürüm notlarında, Kaynak modunda görüntülendiğinde daha düzgün sütunlar sağladığı özellikle belirtilen otomatik tablo biçimlendirme özelliği tanıtılmıştır. Bu, Markdown söz dizimi özelliği değil, belgelenmiş bir düzenleyici davranışıdır. Obsidian 1.5.8 Masaüstü sürüm notları.

Sıradan bir notta şu adımları izleyin:

  1. Notu Canlı Önizleme modunda açın. Gerekirse bu modu düzenleyicinin durum simgesinden seçin.
  2. Tablo Ekle komutunu kullanarak veya sağ tıklayıp Ekle → Tablo seçeneğini belirleyerek tablo ekleyin.
  3. Tablo düzenleyicisinde hücre içeriklerini girin veya düzenleyin. Satır ve sütun eklemek, silmek, taşımak ya da sıralamak için tabloya sağ tıklayın.
  4. Durum simgesinden Kaynak modunu seçip oluşan Markdown’ı inceleyin.
  5. Görüntülenen tabloyu kontrol etmek için Okuma görünümüne geçin.

Mod denetimleri Görünümler ve düzenleme modu sayfasında; tablo ekleme ve bağlam menüsü işlemleri ise Gelişmiş biçimlendirme söz dizimi sayfasında belgelenmiştir.

Modlar arasında sık geçiş yapıyorsanız Canlı Önizleme/Kaynak modunu değiştir komutuna bir kısayol atayın. macOS’ta Cmd+E, okuma ve düzenleme görünümleri arasında geçiş yapar; özellikle iki düzenleme modu arasında geçmek istiyorsanız ayrılmış mod komutunu kullanın. Obsidian görünümleri ve düzenleme modu.

Doğrudan Kaynak modunda yazarken düzensiz boşluk dolgusu oluşursa, daha fazla düzenleme yapmak için yerleşik tablo düzenleyicisine dönün ve sonrasında kaynağı inceleyin. Atıf yapılan belgeler otomatik tablo biçimlendirmeyi ve kaynağın hassas biçimde incelenmesini destekler; ancak her rastgele kaynak düzenlemesinin anında yeniden boşluklarla doldurulacağına ilişkin evrensel bir garanti sunmaz. Küçük bir tabloda hizalama hâlâ bozuksa, aşağıdaki elle uygulama yöntemi size doğrudan denetim sağlar.

Uzun bir düzenlemeden sonra kaynak sütunları nasıl yeniden hizalanır?

Basit bir kural kullanın: Her kaynak sütununu, başlığı da dâhil olmak üzere, içindeki en uzun mevcut girdiye yetecek genişlikte yapın. O sütundaki diğer hücrelere dolgu ekleyin. Bir girdi mevcut boşlukları aşacak kadar uzarsa yeniden hesaplayın.

Yalnızca düz ASCII metin kullanan, adım adım bir örnek aşağıda. Şu tabloyla başlayın:

| Item   | Finish | Count |
| ------ | ------ | ----: |
| Pencil | Matte  |     4 |
| Folder | Linen  |    12 |

Şimdi Folder ifadesini Large sketchbook ile değiştirin. Yeni öğe 16 karakterdir; dolayısıyla ilk sütunda 16 karakterlik bir içerik alanı gerekir. Her sınır borusunun hemen içine bir boşluk bırakın, ardından bu alanı dolduracak kadar sondan boşluk ekleyin:

  • Item 4 karakterdir; sonuna 12 dolgu boşluğu, ardından sınır boşluğunu ekleyin.
  • Pencil 6 karakterdir; sonuna 10 dolgu boşluğu, ardından sınır boşluğunu ekleyin.
  • Large sketchbook 16 karakterlik alanı doldurur; bu nedenle sonrasında yalnızca sınır boşluğuna ihtiyaç duyar.
  • Görsel bir kılavuz olarak ilk ayırıcı hücresini 16 tireye uzatın.

Sonuç, daha önce gösterilen dolgulu tablodur. Yalnızca ilk sütunun genişletilmesi gerekti. Diğer sütunlar boşluklarını ve hizalama işaretlerini korur.

Bu, belirtilen ASCII örneği için elle uygulanan bir biçimlendirme tarifidir; genel bir karakter genişliği algoritması değildir. Günlük düzenlemelerde sonucu sabit genişlikli bir kaynak görünümünde inceleyin. Hücrelerde kapsamlı satır içi biçimlendirme varsa, kaynak genişliğini ters tırnak ve yıldız gibi noktalama işaretleri dâhil, yazılmış karakterlere göre değerlendirin.

Bir dizi düzenlemeden sonra her tuş vuruşunda her satırı ayarlamak yerine tabloyu bir kez hizalayın. Girdiler sık sık paragraflara dönüşüyorsa, tabloda yalnızca kısa bir etiket tutup açıklamayı altında normal metin olarak yazmayı düşünün. Böylece altta yatan bilgiyi kısaltmadan boşlukları koruma ihtiyacı azalır.

Tablo bozulduğunda neleri kontrol etmelisiniz?

Boşlukları ayarlamadan önce yapıyla başlayın. GFM’de başlık ve ayırıcı satırlardaki hücre sayısı eşleşmelidir. Daha az hücre içeren gövde satırlarına boş hücreler eklenir; fazla hücreler yok sayılır. Bu nedenle tablo makul göründüğü hâlde oluşturulan sonuçta içerik eksik olabilir. GFM tablo ayrıştırma kuralları.

Önemli bir düzenlemeden sonra şu tanılama adımlarını izleyin:

  1. Başlık ve ayırıcı satırları karşılaştırın. Her başlığa karşılık bir ayırıcı hücresi verin.
  2. Her gövde satırını inceleyin. Bir değer boş olsa bile amaçlanan hücre sayısını koruyun.
  3. İçerikte düz boru işaretleri olup olmadığına bakın. Kaçış karakteri eklenmemiş bir boru, başka bir sınır olarak yorumlanabilir.
  4. Satır sınırlarını inceleyin. Her tablo satırını tek bir kaynak satırında tutun ve tablo içinde boş satır bırakmayın.
  5. Hedefte önizleyin. Görünümün yanı sıra görüntülenen değerleri de kontrol edin.

Düz boru işaretleri için GitHub, karakterin önüne ters eğik çizgi eklenmesini belgeliyor. Bu eksiksiz örnekte Blue | Green tek hücre içinde kalır:

| Item   | Options       |
| ------ | ------------- |
| Folder | Blue \| Green |

Kaçış karakteri yapısaldır; kaçış eklenmemiş bir borunun çevresine daha fazla boşluk eklemek sorunu çözmez. GitHub’ın düz boru örneği.

Obsidian, bir tablonun içindeki dahili bağlantı diğer adında kullanılan boru işaretinin de kaçırılmasını belgeliyor. Bu, Obsidian’a özgü bir söz dizimi konusudur; kaçış eklenmiş bir diğer ad, bağlantının GitHub’da eşdeğer şekilde çalışacağını tek başına kanıtlamaz. Obsidian tablo biçimlendirme yönergeleri.

Kaynağın daha dar görünmesi için uzun bir hücrenin ortasında Enter tuşuna basmayın. GFM tabloları satır içi içeriği kabul eder ve blok düzeyindeki öğeleri dışlar; çok satırlı genel bir kaynak hücresi biçimi sunmaz. Tek satırlı satırlar kullanışsız hâle geldiğinde uzun açıklamaları tablonun dışına taşıyın. GFM tablo içerik kuralları.

Bakım rutinini kısa tutun: içerik değişikliklerini tamamlayın, hücre sınırlarını inceleyin, etkilenen sütunları yeniden boşluklarla doldurun ve oluşturulan tabloyu gözden geçirin. Obsidian’da yerleşik tablo düzenleyicisiyle başlayıp ardından Kaynak moduna geçmek pratik bir yoldur. Düz metinde belirli bir görünüm istediğinizde elle boşluk doldurma yöntemi yine kullanışlıdır.

Kaynaklar