| Yazar | Belirtilmemiş | | Kurum | Belirtilmemiş | | Tarih | Network Working Group 12 January 1972 | | Durum | Network Working Group Yorum Talebi | | RFC Numarası | 292 |
GİRİŞ
Bu belge, Kasım 1971’in sonlarında Stanford Artificial Intelligence Laboratory’de gerçekleştirilen Network Graphics Group’un ikinci toplantısında ifade edilen görüşleri ve alınan kararları yansıtmaktadır. ARPA ağı içinde grafik verilerinin iletilmesi için önerilen bir Ağ Standart Grafik Protokolünün bir bölümünü açıklar. Bu belgede ele alınan protokolün belirli yönleri, grafiksel bilginin bir kaynaktan (örneğin "Serving Host" üzerindeki bir uygulama programı) bir grafik konsoluna çıktı vermek üzere bir görüntüleme paketine ("Using Host" üzerinde) gönderilen grafik bilgisinin biçimi ve içeriği ile ilgilidir. Bu, 8 bitlik baytların bir dizisi biçimini alacaktır ve grafik çıktı bayt akışı olarak adlandırılacaktır. Özellikle, bu belgenin ilk sürümünde yalnızca grafik verilerinin en basit biçimleri ele alınacaktır. Halihazırda hazırlanmakta olan bir sonraki sürüm çok daha kapsamlı olacaktır. Her durumda bu belge tamamlanmış bir protokolü tanımlamayı amaçlamaz; daha ziyade ağ üzerinde grafik deneyleri için bir temel oluşturmalıdır.
Bu belge grafik girişi biçimini veya içeriğini (Using Host’tan Serving Host’a gönderilen veriler) kapsamaz ve ayrıca ana bilgisayarlar arasında bağlantının nasıl kurulduğunu da ele almaz. Birincisi için bir öneri zamanla bu komite tarafından hazırlanacaktır; ikincisi ise Connection Committee’nin (Network Graphics Group’un bir alt komitesi) görevidir.
Bu RFC, protokolde mevcut olan komutları, bunların alıcı (Using Host) tarafında meydana getireceği etki açısından tanımlar. Açıkça görülmektedir ki, uygulama paketlerinin grafik verilerini iletmekte kullanabileceği bir alt yordam paketi Serving Host üzerinde arzu edilir; ancak bu konuda bu RFC herhangi bir yorum yapmayı amaçlamaz.
Okuyucu, bu protokolde Using Host’un grafik çıktı bayt akışındaki mantıksal hataları Serving Host’a bildirmesine olanak tanıyan herhangi bir mekanizmanın belirtilmediğini fark edebilir. Böyle bir mekanizmanın grafik giriş bayt akışı ile bütünleştirilmesi gerekir; çünkü bu durum bağımsız ana bilgisayarların eşzamanlılığı ile ilgili sorunların çoğunu içerir.
ARKA PLAN
Okuyucunun, ağ grafikleri konusundaki bu tartışmanın bağlamını anlamak için Mike Padlipsky tarafından yazılan RFC 282: "Graphics Meeting Report" belgesine göz atması yararlı olacaktır. Ayrıca Donald Huff tarafından yazılan RFC 285: "Network Graphics" belgesinde açıklanan modeli not etmek de değerli olabilir.
SEVİYE VE BUNA İLİŞKİN TEMEL KURALLAR
Grafik protokolü içindeki işlevler, bu işlevlerin uygulanmasının ne kadar zor olduğuna da kısmen bağlı olarak çeşitli seviyelere ayrılacaktır. Seviye N işlevlerini uyguladığını iddia eden herhangi bir ana bilgisayarın tüm daha düşük seviyeleri de uygulaması amaçlanmaktadır. Böylece, sitelerin seviyeleri kademeli olarak uygulamaya koyması öngörülmektedir. Uygulamalar daha fazla işlev içerecek şekilde sürekli olarak geliştirilecektir ve her uygulamanın grafik alışverişi talep eden uzak bir sitedeki grafik protokolüne kendi seviyesini tanımlayabilmesi amaçlanmaktadır. Bunun bir yan sonucu olarak, her site grafik protokolü için programcı tahsisi konusunda kendi önceliklerini diğer çalışmalarla karşılaştırarak belirleyebilecektir.
Ayrıca niyetimiz, seviye N uygulamasının seviye N+1 hakkında herhangi bir bilgi gerektirmemesidir. Böylece bir site, daha üst seviyelerde yapılacak değişikliklerin uygulanan seviyeyi değiştirmeyeceği yönünde (makul ölçüde) sağlam bir bilgiyle bir seviyeyi uygulayabilir. Bir noktada Network Graphics Group daha önce kesinleşmiş bir seviyeyi yeniden tanımlamaya karar verebilir. Bunun gerçekleşmesi amaçlanmamaktadır, ancak önerilen Grafik Protokolünün deneysel olduğu ve değiştirilmeye ihtiyaç duyabileceği kabul edilmelidir.
Bir başka temel kural daha vardır: belirli bir seviye K için geçerli olan bir komut ve veri akışı, seviye K veya daha yüksek herhangi bir yorumlayıcıda "özdeş" sonuçlar üretmelidir. Bununla, tanımlanmış işlemler kapsamında benzer görüntülerin oluşmasını kastediyoruz. Protokolün şu anda kesin olarak tanımlanmamış yönleri arasında karakter boyutu, karakterin ışın (beam) konumuna göre yerleşimi, metin çıktısındaki kontrol karakterlerinin terminali nasıl etkilediği ve ışın mantıksal ekran sınırlarının dışına taşındığında veya bir çizgi bu sınırların dışında çizildiğinde ne olacağı bulunmaktadır. Bu kural yukarı doğru uyumluluğu zorunlu kılar; böylece düşük numaralı bir seviyenin özelliklerini kullanarak yazılmış bir uygulama, daha yüksek seviyeleri uygulamaya geçmiş sitelerde de çalışmaya devam eder. Ayrıca bu protokolün aşağıdaki ayrıntılı işlem açıklamalarında açıkça belirtilmemiş bırakılan tüm yönleri, gerçek bir uygulamanın kamuya açık tanımında açıkça belirtilmelidir.
Şimdi tüm seviyeler için ortak olacak çerçeveyi açıklıyoruz.
TEMEL VERİ BİÇİMLERİ
Network Standard Graphics Protocol içindeki bilgi, 8 bitlik baytlardan oluşan bir dizi olarak ifade edilecektir. Bir komut, bir komut baytından ve onu izleyen sıfır veya daha fazla argümandan oluşacaktır. Aynı komut baytı her zaman aynı biçimde ve aynı sayıda argüman alacaktır. Her argümanın uzunluğu sabit veya değişken olabilir.
Basit bir argüman türü "değer"dir ("value"); bu, 8 bitlik bir tam sayıdır. Başka bir argüman türü ise "dize"dir ("string"); bu, bir sayım değeri ve ardından (sayım) kadar 8 bitlik bayttan oluşur. Eğer sayım 0 ile 127 arasındaysa tek bir bayt içinde gönderilir. Eğer sayım 128 ile 215 − 1 arasında ise ( üst alma anlamına gelir), ilk baytın en yüksek anlamlı biti bire ayarlanmış şekilde iki bayt içinde gönderilir. İlk bayt sayının en yüksek yedi bitini, ikinci bayt ise en düşük sekiz bitini içerir. Bir dize, uzunluğu değişebilen tek komut argümanı türüdür.
Koordinat verileri, ikinci Network Graphics Group toplantısında önemli tartışmalara yol açmıştır. İki boyutlu bir Mantıksal Koordinat Sisteminin gerekli olduğuna karar verilmiş ve grafik komut bayt akışı için her yorumlayıcının bu koordinat sistemini fiziksel aygıt koordinatlarına eşleştirmekten sorumlu olması kararlaştırılmıştır. Mantıksal koordinat sistemindeki verilerin iki'nin tümleyeni gösteriminde olmasına, kesirli olmasına, ekranın her kenarının birim uzunlukta olmasına ve orijinin çıktı aygıtındaki ekranın merkezine karşılık gelmesine karar verilmiştir. Çıktı aygıtının ekranının düşey (yatay) kenarları X (Y) = −1/2 veya X = +1/2 − e doğrularına karşılık gelir; burada e, kesirli verinin hassasiyetine bağlı küçük bir pozitif sayıdır. Özellikle (−1/2, −1/2), (−1/2, 1/2 − e), (1/2 − e, −1/2) ve (1/2 − e, 1/2 − e) noktaları mantıksal ekranın köşelerinde görülebilir noktalar olacaktır. (Kare olmayan bir görüntüleme yüzeyi durumunda, uygulayıcı kendi kararını verebilir; ancak mümkün olan en büyük kare alanın kullanılması önerilir.) Böylece Mantıksal Koordinat Sisteminin koordinatları −1/2 ile +1/2’den biraz daha küçük bir değere kadar uzanan noktalar içerdiğini söyleyeceğiz.
Koordinat verisi alan komutlar çeşitli kiplerde kullanılabilecektir. Mutlak kipte bir konum, Mantıksal Koordinat Sistemindeki koordinatları verilerek belirtilir. Göreli kipte ise konumun koordinatları ile mevcut konumun koordinatları arasındaki fark belirtilmelidir. Buna göre mutlak kipli bir işlem için argüman olan koordinat verisi −1/2 ile +1/2 − e aralığında olmalı, göreli kipli bir işlem için olan ise −1 + e ile +1 − e aralığında olmalıdır.
İkinci Graphics Group toplantısında, gelecekte çok büyük bir koordinat uzayına (her kesirli koordinat için çok sayıda bit hassasiyeti) izin verilmesi yönünde ilgi ifade edilmiştir. Bunun, her koordinat verisinin 8 bitlik bayt cinsinden uzunluğunun bir kip olarak ayarlanmasına izin verilerek yapılması planlanmaktadır. Toplantıda şimdilik koordinat başına iki baytın yeterli olacağına karar verilmiştir. Buna göre yukarıdaki tartışmada e değeri 2**(−15)’tir (işaretli 15 bitlik kesirli bir koordinatın en düşük anlamlı bitindeki bir değer).
Metin verileri, çıktı aygıtında görüntülenmek üzere çeşitli komutların argümanı olarak iletilecektir. Karakterleri temsil etmek için Network ASCII kullanılacaktır. Protokolün en düşük seviyelerinde yalnızca tek bir karakter boyutu mevcut olacaktır — görüntüleme aygıtında "normal" kabul edilen boyut. Eğer aygıtın "normal" bir boyutu yoksa, satır başına 72 karakter tercih edilir. Daha sonraki aşamalarda değişken karakter boyutu eklenebilir.
Ayrıca en düşük seviyelerde kontrol karakterleri, aygıtın elinden geleni yapabilmesi için doğrudan aygıta iletilecektir. Ancak grafik toplantısındaki genel görüş, makul derecede düşük (ancak sıfır olmayan) bir seviyede carriage return, line feed ve backspace karakterlerinin doğru şekilde yorumlanması gerektiği yönündeydi.
KOMUT KODLARI
Grafik protokolündeki her komuta, bayt akışında bu komutu temsil edecek negatif olmayan bir değer atanacaktır. Değerler ile komutların ilişkilendirilmesini sağlayan algoritma oldukça hassas bir konudur. "En iyi" algoritma için beş veya on farklı ölçüt vardır ve her biri farklı bir vurgu taşır. Bu karmaşık düğüm, bu öneride komutların yaklaşık olarak seviyelerine göre sıralanması ve ardından numaralandırılması yoluyla çözülecektir. Buna ek olarak, aynı seviyede birden fazla yakından ilişkili komut bulunuyorsa, anlam farklılıklarının bit yapılandırmaları aracılığıyla kodlanması için bazı girişimlerde bulunulacaktır. Daha sonraki değerlendirmeler sıralamada değişiklik önermeye yol açsa bile, bu komitenin görüşü numaralandırmanın değiştirilmemesi yönündedir. Ancak bu konu kesin olarak karara bağlanana kadar, herhangi bir uygulamanın komut kodlarının yeniden atanabileceği olasılığını dikkate alması kuvvetle tavsiye edilir.
SEVİYE 0 PROTOKOLÜ İÇİN ÖZEL ÖNERİ
Seviye 0’ın çok basit tutulması önerilmektedir. Bunun nedeni, uygulamanın hızlı biçimde gerçekleştirilebilmesi ve protokol ile deneylere başlanabilmesidir. Bir başka neden ise en az güçlü ana bilgisayarların ve hatta programlanabilir terminallerin bile bunu uygulayabilmesidir. Bu doğrultuda şu "kural" belirlenmiştir: bir komut yalnızca çıktısı mevcut komuta ve komutun başlangıcındaki "ışın konumu"na bağlıysa uygulanmalıdır. Başka bir deyişle, seviye 0 yorumlayıcısının "kipler" veya yığın benzeri yapılar için herhangi bir iç depolamaya sahip olması gerekmez. Bu kısıtlama ile seviye 0 için çok basit bir uygulamanın mümkün olması umulmaktadır. Özellikle, belki de bir gün seviye 0 kodunu belirli bir terminalin kendi koduna dönüştüren bir donanım çevirici geliştirmek mümkün olabilir.
Seviye 0 için işlem kodu atamasında 4, 2 ve 1 bitlerinin move, line ve dot komutları için özel anlamlara sahip olduğuna dikkat edin. Özellikle 1 biti mutlak ile göreli veri kipini kodlar, 4 biti görünür bir çıktının oluşup oluşmayacağını kodlar ve 2 biti görünür çıktının bir çizgi mi yoksa bir nokta mı olduğunu belirler.
SEVİYE 0: KOMUT ÖZETİ
Aşağıda seviye sıfırdaki komutların (ve sözdizimlerinin) bir listesi verilmiştir. Bu komutların ayrıntılı açıklamaları bir sonraki bölümde yer almaktadır. Protokolle ilgili komutlar Connection Committee tarafından eklenebilir. (Şu anda 128 ile 255 arasındaki işlem kodlarını talep etmektedirler.)
(Temel Veri Biçimleri bölümünde açıklandığı gibi, <x>, <y>, <x delta> ve <y delta> iki baytlık koordinat değerleridir; <string> bir sayım ve ardından (sayım) kadar bayttan oluşur; <value> ise sekiz bitlik bir sayıdır.)
| Decimal | Octal | Binary | Format |
|---|---|---|---|
| 0 | 0 | 00000000 | Null |
| 1 | 1 | 00000001 | Ekranı sil ve ışını sıfırla |
| 2 | 2 | 00000010 | Move Absolute <x> <y> |
| 3 | 3 | 00000011 | Move Relative <x> <y> |
| 4 | 4 | 00000100 | Draw Absolute <x> <y> |
| 5 | 5 | 00000101 | Draw Relative <x delta> <y delta> |
| 6 | 6 | 00000110 | Dot Absolute <x> <y> |
| 7 | 7 | 00000111 | Dot Relative <x delta> <y delta> |
| 8 | 10 | 00001000 | Text <string> |
| 9 | 11 | 00001001 | TextR <string> |
| 10 | 12 | 00001010 | End of Picture |
| 11 | 13 | 00001011 | Escape <value> <string> |
SEVİYE 0: KOMUT AÇIKLAMALARI
0 — Null İfadesi ("null")
Bu ifadenin hiçbir argümanı yoktur ve hiçbir etkisi yoktur.
1 — Ekranı sil ve ışını başlangıç noktasına sıfırla ("Erase")
Bu komut yeni bir resmin çizilmek üzere olduğunu belirtir. Her zaman (eninde sonunda) ardından gelen bir End of Picture komutu ile eşleşmelidir.
2 — Işını görünmez şekilde mutlak konuma taşı ("Move Absolute") <x coordinate> <y coordinate>
Hiçbir şey çizilmez; ışın belirtilen mutlak x, y konumuna yerleştirilir.
3 — Işını göreli miktarda görünmez şekilde taşı ("Move Relative") <x delta> <y delta>
Hiçbir şey çizilmez; ışın x ve y yönlerinde belirtilen miktar kadar kaydırılır.
4 — Mutlak konuma çizgi çiz ("Draw Absolute") <x coordinate> <y coordinate>
Mevcut ışın konumundan belirtilen mutlak x, y konumuna bir çizgi çizilir.
5 — Göreli konuma çizgi çiz ("Draw Relative") <x delta> <y delta>
Mevcut ışın konumundan delta x ve delta y kadar uzaktaki konuma bir çizgi çizilir.
6. Mutlak Konumda Bir Nokta Göster
("Dot Absolute") <x coordinate> <y coordinate>.
Işın görünmez şekilde mutlak x, y konumuna taşınır ve orada bir nokta gösterilir.
7. Göreli Konumda Bir Nokta Göster
("Dot Relative") <x delta> <y delta>.
Işın x ve y yönlerinde belirtilen miktar kadar görünmez şekilde taşınır ve orada bir nokta gösterilir.
8. Metin Göster
("Text") <string>.
Mevcut ışın konumunda, kullanılan aygıt için normal boyutta bazı karakterler görüntülenir. <string>, bir <count> değeri ve ardından count kadar karakterden oluşur. Eğer "normal boyut" yoksa, satır başına yetmiş iki karakter görüntülenecek şekilde bir boyut seçilir. Dizgedeki karakterler ağ ASCII kodlaması ile temsil edilir: 0 ile 127 (ondalık) arasındaki tüm kodlara izin verilir. (Seviye sıfırda, kontrol karakterlerinin nasıl ele alınacağı belirtilmemiştir.)
Işının bu komutun yürütülmesinden sonra nerede bulunduğu belirtilmemiştir; yalnızca hemen ardından gelen başka bir Display Text komutunun metnini önceki dizeye ekleyeceği garanti edilir. (TEXT komutunun kullanımı önerilmez; bunun yerine TextR kullanın.) İlk karakterin başlangıç ışın konumuna göre konumu belirtilmemiştir.
9. Metni Görüntüle ve Işını Geri Yükle
("TextR") <string>.
Geçerli ışın konumunda, çalıştırılan aygıt için normal boyutta bir karakter dizisi görüntüle ve ardından ışını komuttan önce bulunduğu konuma yeniden yerleştir. <string>, bir <count> değerinin ardından count kadar karakterden oluşur. Eğer "normal boyut" diye bir kavram yoksa, satır başına yetmiş iki karakter görüntülenecek şekilde boyutu seç. Dizideki karakterler ağ ASCII kodlamasıyla kodlanmıştır; 0 ile 127 (ondalık) arasındaki tüm kodlara izin verilir. (Seviye sıfırda, kontrol karakterlerine ne olacağı belirtilmemiştir.) İlk karakterin başlangıç ışın konumuna göre konumu belirtilmemiştir.
10. Resmin Sonu
("Endpic").
Bu komut yeni bir resmin sonunu belirtir. Öncesinde gelen bir Erase komutuyla eşleşmiş olmalıdır.
11. Aygıta Özgü İşlemlere Kaçış
("Escdev") <value> <string>.
Eğer "value" (Protocol Committee tarafından) çalıştırılan aygıta atanmış kod ise, <string> içindeki sekiz bitlik baytları (bayt sayısını belirten bir <count> ile başlar) incelemeden doğrudan aygıta ilet. Aksi takdirde bu komutu yok say. Eğer aygıt 8 bitlik bilgiyi kabul etmiyorsa, veriyi aygıta özgü bir biçimde yeniden düzenle; örneğin yedi bitlik bir aygıt için en yüksek anlamlı biti atmak ya da beş adet 8 bitlik baytı tek bir 36 bitlik sözcükte toplamak ve yine en yüksek anlamlı bitleri çıkarmak gibi. Dizideki baytların gerçekleştirdiği işlem, yorumlayıcının muhtemelen bağımlı olabileceği aygıt içindeki herhangi bir donanım ışın konum yazmacını değiştirmemeli (ya da en azından eski durumuna geri getirmelidir).
Bu komut aslında kullanılmamalıdır; belirli uygulamaların kip ayarlaması ve diğer aygıta özgü işlemleri yapabilmesi için seviye 0'a dahil edilmiştir. Örneğin ARDS terminalleri isteğe bağlı olarak bağımsız biçimde adreslenebilen birkaç çıkış osiloskobuna sahip olabilir. Seçim mekanizmasının durumu yalnızca belirli bir ASCII karakter dizisi terminale ulaştığında değişir. Bu nedenle, takip eden komutların hangi osiloskop(lar)ı etkileyeceğini seçmek için ESCDEV kullanılır. (Geçerli durum Using Host üzerindeki grafik paketine görünmez.)
Ayrıca, başka bir terminal üreticisinin farklı bir kod dizisine yanıt veren benzer bir seçeneğe sahip olduğunu varsayalım. Bu olasılık, belirtilen <value> değerine bağlı olarak ESCDEV komutunun koşullu biçimde yok sayılması fikrinin gerekçesidir. Belirli bir uygulamanın yalnızca ARDS veya bu ikinci üretimin (çoklu osiloskop seçeneğiyle) çıktısına gönderim yapacağı biliniyorsa, uygulama her zaman iki ESCDEV komutu gönderebilir: biri yalnızca ARDS terminalleri için geçerli, diğeri ise yalnızca ikinci üretim için geçerli olacak şekilde.
Ek 1: Grafik Protokolü Bayt Akışı için BNF
Aşağıdakiler için anahtar:
- Non-terminal semboller
<>içinde gösterilir. - Belirli sekiz bitlik değerleri temsil eden anahtar sözcükler büyük harflerle yazılmıştır.
- Anlamı okuyucu için açık olan terminaller küçük harflerle yazılmıştır.
empty_stringifadesinin "sıfır bayt" anlamına geldiğine dikkat edin; "whosesıfırdır" anlamına gelmez.
::= empty_string
|
::=
::= empty_string
|
::=
|
::=
|
::=
|
|
|
|
|
|
|
::= ERASE
::= ESCDEV
::= NULL
::= ENDPIC
::= MOVEA
::= MOVER
::= DRAWA
::= DRAWR
::= DOTA
::= DOTR
::= TEXTR
::= TEXT
::=
::=
::=
::=
::= işaretli, iki'nin tümleyeni kesri; aralık
-1/2 ile +1/2'den küçük
::= işaretli, iki'nin tümleyeni kesri,
aralık -1 ile +1 arasında (uç noktalar hariç)
::= 7 bitlik negatif olmayan tamsayı
| 15 bitlik negatif olmayan tamsayı;
"excess 2**15" gösterimiyle ifade edilir
::= count adet 8 bitlik bayt
::=
::= 8 bitlik tamsayı
Bu RFC, çevrimiçi RFC arşivlerine eklenmek üzere Kelly Tardif, Viagénie tarafından 10/99 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.