ticoAg/ChineseCorpus-Kaggle-fanti huggingface dataset:
她於2004年6月13日（40歲生日前兩天）誕下了他們第一個女嬰Coco Riley Arquette，他們本來打算讓孩子跟從考克斯媽媽的名字而取名Courteney Cox Arquette的，但丈夫家人堅決反對，因為讓孩子跟一個在世的親戚的名字是有悖猶太教的傳統的。Coco當考克斯還小的時候她的一個朋友給她的媽媽起的昵稱。考克斯的密友，同時也是六人行的聯合主演之一的詹妮弗·安妮斯頓是孩子的干媽。
她於2010年10月11日宣布和大衛·阿奎特（David Arquette）分居，並於2012年6月13日向洛杉磯高等法院以難以彌補的分歧為理由申請離婚。
* ''Down Twisted'' (1987)
* ''決勝時空戰區Masters of the Universe'' (1987)
* ''魔繭2Cocoon: The Return'' (1988)
* ''Mr. Destiny'' (1990)
* ''燃燒的野百合Blue Desert'' (1991)
* ''Shaking the Tree'' (1992)
* ''愛情酸甜苦辣The Opposite Sex And How To Live With Them '' (1993)
* ''王牌威龍Ace Ventura: Pet Detective'' (1994)
* ''驚聲尖叫Scream'' (1996)
* ''Commandments'' (1997)
* ''驚聲尖叫2Scream 2'' (1997)
* ''賭命人The Runner'' (1999)
* ''驚聲尖叫3Scream 3'' (2000)
* ''驚天駭地3000 Miles to Graceland'' (2001)
* ''The Shrink Is In'' (2001)
* ''Get Well Soon'' (2001)
* ''異星人三角戀Alien Love Triangle'' (2002)
* ''November'' (2004)
* ''鐵男總動員The Longest Yard'' (2005)
* ''瘋狂農莊-動物也開趴Barnyard'' (2006) (配音)
* ''超人集中營Zoom'' (2006)
* ''旅行者The Tripper'' (2007)
* ''天方夜談'' (2008)
* ''驚聲尖叫4Scream 4'' (2011)
* ''驚聲尖叫5Scream 5'' (2022)
* ''As the World Turns''（1984年出演）
* ''Code Name: Foxfire'' (1985)
* 《超人特攻隊》 ''Misfits of Science'' (1985-1986)
* ''Murder, She Wrote''（“Death Stalks the Big Top”上下集中的客串明星（1986）)
* ''Sylvan in Paradise'' (1986)
* ''If It's Tuesday, It Still Must Be Belgium'' (1987)
* 《一家親》（''Family Ties''1987年－1989年間出演）
* ''Till We Meet Again'' (1989)
* 《宋飛傳》 ''Seinfeld''（1994年3月17日客串）
* 《六人行》（''Friends''，1994年－2004年出演）
* 《》（''Dirt''，2007年至2008年）
* 《熟女當道》（''Cougar Town''，2009至2015年）
PANOSE 是一種依照字體外觀來進行分類的方法。對於未知的字體，可以透過PANOSE體系將字體的外觀特徵整理並且與其他字體歸類比較。
PANOSE定義了幾個範圍：Latin Text, Latin Script, Latin Decorative, Iconographic, Japanese Text, Cyrillic Text, Hebrew。PANOSE的原形在1985年由 Benjamin Bauermeister 所開發，當時一個字體由七個16進位數字所定義，現在則發展為十個。這每一個數字都定義一種視覺外觀的單位，像是筆劃的粗細或是字體襯線的樣式。
舉例來說，Times New Roman字體，依照PANOSE系統的定義如下：
Family Kind
2 (Latin text)
Serif Style
2 (Cove)
6 (Medium)
3 (Modern)
5 (Medium low)
Stroke variation
4 (Transitional)
Arm style
5 (Straight arms)
Letterform
2 (Round)
3 (Standard)
X-height
4 (Large)
* PANOSE 1.0 Reference
* PANOSE 2.0 White Paper
背景為黃泥涌村，前景是1873年的跑馬地馬場。
黃泥涌村是香港昔日一條村落，位於香港島黃泥涌谷（今跑馬地）一帶，今快活谷馬場及其南面部份。
黃泥涌村是一個百年古老小農村，村民吳姓及葉姓，在黃泥涌谷種養稻米、蔬菜、活豬及家禽為生。也有些以採石建築村屋及買賣石材物料為業。石材主要來自摩理臣山。
1840年代初，英國人出現，原計劃發展黃泥涌村附近作為商業中心，不過入住該地的白種人很多都會死於瘧疾、熱癥，香港政府唯有取消此發展項目。死去的英國人多數土葬於附近，因此後稱「快活谷」或「愉園」。經考究此傳染病來自黃泥涌谷的水田滋生的蚊蟲，所以政府把原有稻田和菜園的谷地填平，並於1846年改建成賽馬場。原居民被安置到晉源街、桂芳街、聯興街等地。
及後，黃泥涌村慢慢被都市化，建成為成和道、景光道、毓秀街、昌明街、奕蔭街、集祥街、棉發街等跑馬地住宅區。
跑馬地北帝譚公廟
* 跑馬地北帝譚公廟：位於藍塘道與雲地利道之交界，在1901年由黃泥涌村村民興建。之後於1928年重建，在雲地利道的路邊小山坡上，善信要徒步石級十數而至其廟宇，其後座為天后宮，兩側為百家祠，石級高處可以居高回望藍塘道路口。
* 愉園：現址是養和醫院，數十年前是一處遊樂埸，名為愉園遊樂場，場內有亭臺樓閣、假山等中式佈局，開業之時有新鮮感，之後原地改為療養院，再之後改建成為著名私家醫院。
*  香港地方: 黃泥涌村村民建有跑馬地北帝譚公廟
*  攝於一八七三年之馬場全景，背景為黃泥涌村
*  開埠以前，黃泥涌村在現稱的跑馬地為中心的山谷一帶。
基于X11協議的窗口系統將和窗口管理器保持為獨立的部件
X視窗管理器是X窗口系統中，用來控管視窗外觀和放置方式的視窗系統軟件，主要用於類Unix系統。
X視窗管理器和蘋果公司的Macintosh和微軟公司的Windows的操作環境具有不同的使用模式。后兩者都有長期固定的用戶界面和操作模式，而這些都是由開發商決定的，用戶無法更換或者只能作微小調整。X視窗管理器提供完全開放的，和圖像顯示軟件無關的用戶界面。用戶可以自由選用窗口管理器。這些管理器可以擁有完全不同的特性，包括：
*用于啟動程序或者進行設置的菜單
*啟動程序的方式，可能是命令行式的，也可能是圖形化的，比如停靠欄。
*多桌面、虛擬桌面（比顯示器尺寸要大的桌面）和用于切換桌面的桌面切換器（pager）。
*和桌面環境的整合程度。部分X窗口管理器提供更加完整的用戶界面、系統軟件和應用程序。
當視窗管理器開始運作時，X伺服器和客戶端之間的互動，會重新導向到視窗管理器。每當要顯示一個新視窗時，這個請求便會被重新導向到視窗管理器，它會決定視窗的初始位置。此外，大部分較新的視窗管理器會改變視窗的親屬關係，通常會在視窗頂部加上標題列，並在視窗周圍加上裝飾性的框架。這兩個部分皆由視窗管理器來控制，而不是其它程式。因此，當使用者點擊或拖曳那些元件時，視窗管理器會進行適當的動作（如移動或改變視窗的大小）。
視窗管理器也負責處理圖示，圖示並不存在於X Window核心協議的層次中。當使用者將視窗最小化時，視窗管理器會取消視窗的映射（使其不可見），並完成適當的動作，將視窗改顯示成圖示。某些視窗管理器並不支援圖示功能。
視窗管理器主要的目標，就如同其名，是用來管理視窗的。許多視窗管理器提供附加的功能，如處理滑鼠在根視窗上的點擊，呈現出窗格以及其它的視覺化元件，處理按鍵（例如 Alt-F4 可關閉視窗），判定哪一個應用程式在啟動時執行等等。
幾種特殊的視窗管理器如下。
虛擬視窗管理器使用了虛擬的螢幕畫面，其解析度可大於顯示器的解析度。當希望有較多的視窗時，這個功能也很有用。虛擬視窗管理器包括有 FVWM、Tvtwm、HaZe 等等。
平鋪式視窗管理器是以不重疊畫面的方式組織螢幕畫面（故稱為平鋪式），相對於傳統的方式，它更近似於以坐標為基礎的疊置物件（視窗），其嘗試模仿辦公桌的式樣。
第一個平鋪式視窗管理器是 larswm，隨後是 Ion。以下是平鋪式視窗管理器的列表：
*Blackbox (minimalist)
*Fluxbox （輕量級，基于Blackbox）
*FVWM（twm基礎上開發的的 虛擬窗口管理器）
*KWin（原名 KWM,  KDE默認的窗口管理器）
*Metacity（ GNOME 2.2後成為默認的窗口管理器）
*MWM (Motif Window Manager)
*Openbox（ LXDE默認的窗口管理器，基于Blackbox）
*Sawfish （原名 Sawmill，前GNOME系統默認窗口管理器）
*twm （X Window系統X11R4以來的默認窗口管理器）
*Xfwm， （Xfce默認的窗口管理器)
*5Dwm (derived from mwm, true SGI look&feel)
*9wm （複製 九號計畫 原先的視窗系統）
*amiwm  Amiga workbench unix clone.
*Compiz (a compositing window manager) and Beryl (window manager) an under development fork of it
*EvilPoison  (a fork of evilwm with Ratpoison-like keybindings)
* (平鋪式窗口管理器，為鍵盤用戶設計)
*JWM (Joe's Window Manager)
*Luminocity (experimentation in compositing)
*OLWM（and OLVWM  with virtual desktops, OPEN LOOK window managers）
*Qvwm (Windows 95/98 look-alike)  (list of forks)
*Scwm (the Scheme constraints window manager)
*Orion A nested (tiled or floating) window manager written in Scheme and scsh
*swm (the original virtual desktop implementation)
*Toy'd（ HomePage  GoogleProject a portable window manager for MS-Windows & UNIX / Linux platforms）
*XPwm（for XPde，Windows XP Look alike）
*Xmonad（平鋪窗口管理器）
*Re-parenting window manager for a popular implementation technique
*X Window System protocols and architecture for context
*Compositing manager for another kind of manager in X
*Compositing window manager that combines two roles in one program
*Windowing system for other platforms than the X Window System
*  ''Window Managers for X'' by Matt Chapman
*  ''The Other Window Managers''  - extensive review of window managers (2003)
*  ''Window Managers'' - list of window managers with minimal comments (2004)
*  ''Software List:Window Managers'' - list of window managers with summaries
*  名詞解釋：Matchbox
扶西．黎剎醫生和家人等曾居於此
列拿士地臺位於太子臺與摩羅廟街中間
列拿士地臺位於香港中環半山區扶手電梯地帶，為行人專用區，全長約63米。西至卑利街，東達些利街，與太子臺及芝古臺平行。
此街的的英文名稱「」，是“Alexander”的倒拼，因此，有傳聞列拿士地臺當初命名是紀念一名叫為亞歷山大的人，估計是由於當時負責翻譯街名是中國人，習慣由右向左書寫，因而把亞歷山大的英文倒轉翻譯，拼成“Rednaxela”這名稱。後來因街名決定了，政府也沒有對這街名作出修改。
儘管香港有上述的傳說，但曾在香港讀書與在香港出版社任過編輯，後來以「黃信怡」等筆名在菲律賓《世界日報》撰寫專欄的菲律賓華人作家江樺，卻持有不同的意見。
江樺認為這一種傳說無法成立的理由有四：
#懂得英語是當年在香港殖民地政府擔任翻譯工作的中國人必具的起碼條件，既懂得英語，不可能不知道英語拼寫該從左至右
#倘若當時這地方是先以英文名來命名，而要紀念的是一位名為Alexander的人士，那麼其完整英文地名應該是“Alexander Terrace”，而從事該項翻譯工作的中國人所倒轉翻譯的也該是“Alexander Terrace”整個英文名（Ecarret Rednaxela），沒道理選擇性地只倒轉“Alexander”這人名而已。
#假如中文名是誤譯，那麼，其結果也只是中文名跟英文名不相稱而已，不會連英文也一同倒拼。
#在英國統治的早期，香港街道命名的最終決定權掌握在英國人手中。即使譯者擺了烏龍，誤把Alexander Terrace寫作Rednaxela Terrace，呈請英國人批示時，英國人也不可能不發覺。
#根據香港節目《學是學非》，第五個不成立原因是因為在中環，也有一座歷山大廈 （Alexandra House），是在香港開埠初期（1904年）的建築物，但翻譯無誤。
江樺考證後，發現了十九世紀二十年代有位名為Robert Alexander Young的反奴隸制度志士，他在1829年發表了著名的《埃塞俄比亞人宣言》（Ethiopian Manifesto）。Robert Alexander Young在宣言中，給了所有散居在非洲境外的非洲人予以「埃塞俄比亞人」的身分。於是Ethiopian延伸出了「黑人」的新意。該宣言引用了聖詩中的「王子要走出埃及，埃塞俄比亞將很快伸出雙手向上帝。」去呼籲所有的人黑色自覺認同自己是「埃塞俄比亞人」。Robert Alexander Young在宣言中把Alexander倒串成Rednaxela，並自稱為Rednaxela。人們遂把Robert Alexander Young簡稱為Rednaxela。Rednaxela Terrace的真正由來，相信是早期香港政府打算以之紀念這古典黑人民族主義者。
列拿士地臺近些利街街口有一個牌，上面寫著古物事務監督認定，菲律賓國家英雄扶西·黎剎醫生和家人曾經在此居住，這都印證了這地區跟有色人種民權運動的歷史淵源。
但另一方面，亦有論者認為，英國殖民者沒理由要紀念一個搞革命的民族主義者。而且當年在香港政府擔任翻譯者懂得英語，不等於他們英語水平良好。香港路名不乏錯譯的例子，例如眾坊街（Public Square Street）就曾被譯成「公眾四方街」。路名的由來仍未有定論。
97年落成的單幢樓帝華臺
協利集團發展的
目前列拿士地臺及卑利街交界有幢建築名為帝華臺，在列拿士地臺1號，英文為 ，估計也是取名自列拿士地臺。
列拿士地臺8號英文為（ACTS Rednaxela），由協利集團（Goldig Investment Group）發展。吳家耀（Carl Gouw）代表發展商和（ACTS）與建築師張智強Gary Chang和Edge Design Institute 合作設計這座建築 。這項目獲得香港設計中心頒發的設計獎  並在 Apple TV的電視劇 Home放映。協利集團於 2012 年以 2 億港元出售 (ACTS Rednaxela)，(ACTS) 繼續營運服務式公寓。該建築模型於西九文化區M+博物館展示 。
* 高深莫測的香港街道名稱 ，CNN Travel，2010-9-20
位于原南京虹橋20號的國民政府資源委員會舊址
資源委員會是中華民國政府於1932年至1952年期間負責重工業發展與管理相關工礦企業的政府機構。它實際上是中國抗日戰爭國民政府的最高經濟領導部門，它不但支撐了中國抗戰，而且為戰后的中國工業現代化打下了基礎。早期工作為秘密進行，至1938年3月16日才以「經濟部公布」方式對外公布，其納粹德國的資金與技術伙伴合步樓始終是秘密進行。
*1932年11月1日，中華民國參謀本部於南京成立國防設計委員會，為資源委員會的前身。
*1935年4月1日，國防設計委員會與兵工署資源司合并為資源委員會，隸屬國民政府軍事委員會。資源委員會及其前身曾一度由蔣介石兼任委員長，翁文灝、錢昌照分任正副主任秘書長，負責實際運作。
*1938年2月，資源委員會改隸中華民國經濟部，由時任經濟部部長翁文灝兼主任委員，錢昌照任副主任委員。
*1946年5月20日，資源委員會擴編直屬行政院而成為行政院資源委員會，后由孫越崎任主任委員。資源委員會主要任務為負責資源的調查研究和動員開發，后來逐漸發展成為重工業的主管部門。其產業活動主要集中在與軍事工業相關的鋼鐵、動力、機電、化學等基本工業領域。1946年，資源委員會擁有的工礦企業：電業28個單位，煤業24個單位，石油1個單位，金屬礦12個單位，鋼鐵業10個單位，電器業4個單位，化學業13個單位，水泥業4個單位，糖業1個單位；工人總數189千人，其中礦業工人113千人、工業工人76千人。
**3月，中華民國政府為動員戡亂，將資源委員會縮編改隸經濟部。
**10月，中華人民共和國成立后，資源委員會在大陸的各廠礦被中華人民共和國政府接收。
**12月，資源委員會隨中華民國政府撤退至臺灣。
*1950年3月26日，資源委員會臺灣鋼皮廠開工。
*1952年8月，資源委員會縮編為經濟部國營事業司。
*1969年2月，經濟部國營事業司改組為經濟部國營事業委員會。
中國社會科學院近代史研究所研究員李學通將資源委員會的主要工作按時序分為三個階段：“第一階段是從九一八事變到七七事變，這一階段是備戰，主要是進行調查；第二階段，特別是1937年八一三事變之后到1938年之前的半年，主要是做抗戰初期的經濟轉移，或者叫經濟內遷；第三階段，是1938年之后到中國抗日戰爭結束，主要是進行大后方經濟建設。” 按工作類別來區分，則主要包括以下幾個部分。
資源委員會于1936年3月制訂重工業五年建設計劃，提出5年內投資2億7千余萬元，興建鋼鐵、有色冶金、機械、電力、電器、化工、燃料等工業的30余座大、中型廠礦。并制定了盡量利用外國資本，引進國外技術的方針。1936年6月落實為中德三年計劃。
1936年，在湖南湘潭下攝司籌建重工業基地，共購地10022.5畝建設中央鋼鐵廠、中央機器制造廠、中央電工器材廠以及為其服務的湘江電廠，其中4083.54畝為中央機器制造廠和中央電工器材廠用地，鋼鐵廠占地5938.97畝。并興辦湘潭煤礦、四川龍溪河水電廠等二十余家重工業廠礦。
1944年和1946年資源委員會邀請美國水壩工程師約翰·L·薩凡奇到長江三峽測量三峽工程的可行性。
* 中華民國國史館：《資源委員會檔案史料初編》，1984年.
* 《中國大百科全書》《中國歷史》分卷
阿雷西博天文臺是坐落在波多黎各阿雷西沃的射電天文臺。其主要觀測設備為阿雷西博望遠鏡。
截至2018年，天文臺由中佛羅里達大學、楊企業和根據與美國國家科學基金會（NSF）的合作協議管理和營運。這個天文臺的正式名稱是“國家天文學和電離層中心”（NAIC），也是該組織的唯一設施。從20世紀60年代建造至2011年，天文臺由康乃爾大學管理。
阿雷西博射電望遠鏡口徑為305米，建成于1963年，落成后即成為世界上最大的單孔徑望遠鏡，該記錄一直保持到2016年7月，被中國的500米口徑球面射電望遠鏡（FAST）所取代。該望遠鏡主要用于對射電天文學、大氣科學、雷達天文學等領域進行研究。想要使用該天文臺的科學家需要提交研究計畫交由獨立的科學委員會評估。
2008年，阿雷西博天文臺被列入美國的國家史蹟名錄；又于2008年10月3日，被列入美國國家公園管理局的每周特色清單中；后于2001年，被列入IEEE里程碑列表中。該天文臺還設置遊客中心供游客觀賞。
2017年9月21日，颶風瑪莉亞帶來的強風導致430MHz線路饋送斷裂並掉到主鏡盤上，損壞了38,000塊鋁板中的約30塊。因阿雷西博的觀測資料依賴于位於圓頂中的饋送和接收器傳送，而非使用線路饋送，颶風造成的損傷對天文臺影響很小。
2020年8月10日，望遠鏡的輔助鋼纜斷裂，在望遠鏡反射盤上砸出了長的破口；同年11月6日，同一高塔上的另一根主承重鋼纜斷裂。因為望遠鏡本身結構有災難性故障之虞、剩余鋼纜可能無法再支持設計的重量、而且任何維修嘗試都有可能威脅到維修工人的性命，美國國家科學基金會于該年11月19日決定將天文臺的射電望遠鏡退役并準備拆除。
2020年12月1日凌晨，由于塔尖徹底折斷，望遠鏡約的接收設備平臺墜落并砸毀了望遠鏡反射盤（無線電波天線）表面，未造成人員傷亡，但望遠鏡本身全毀。
阿雷西博天文臺主要的接收盤面建築在巖溶留下的凹陷滲穴中，直徑為。盤面由鋼纜網支撐的38,778片穿孔鋁板製成，每片的面積約。盤面下的地面可以進入，並種植遮陽的植被。
天文臺有4架雷達發射機，在2380MHz具有20TW（連續），在430MHz是2.5TW（脈衝峰值），在47MHz是300MW，8MHz是6MW。
反射器是球面反射器，而不是拋物面反射器。為了瞄準裝置，接收器被移動以攔截由半徑的圓球盤表面反射來自不同方向的信號。當接收器不在焦點時，拋物面鏡會有不同的像散，但是球面像差在每個地方都是均勻的。
接收器是重達900噸的平臺，由三個鋼筋混凝土高塔拉撐的18根電纜懸吊在盤面上方，其中一座塔高，另兩個塔高，而它們的頂部都在相同的高度上。平臺有一個稱為方位臂的長可旋轉的弓形軌道，承載著接收天線和第二級與第三級反射器。這使得望遠鏡可以觀測以天頂為中心，南北共40度（從緯度-1度至+38度）的天空能見圓錐體內的任何區域。波多黎各的位置接近北回歸線，這讓阿雷西博望遠鏡能夠觀察太陽系中的行星在北半球時的軌道。比土星更遠的天體，因為電磁波往返的光程時間比可追蹤的2.6小時還要長，因而限制了對更遙遠物體的雷達觀測。
* 500公尺口徑球面射電望遠鏡
阿雷西博射電望遠鏡是位于阿雷西博天文臺的單口徑射電望遠鏡，1963年建成，2020年完全損毀。
1963年，阿雷西博望遠鏡建成。其口徑為305米，落成后即成為世界上最大的單孔徑望遠鏡，該記錄一直保持到2016年7月，被中國的500米口徑球面射電望遠鏡（FAST）所取代。
2001年，阿雷西博望遠鏡被列入IEEE里程碑列表中。2008年，阿雷西博天文臺被列入美國的國家史蹟名錄。同年10月3日，被列入美國國家公園管理局的每周特色清單中
阿雷西博信息，信息本身沒有顏色，顏色是人為標注用于區分的
阿雷西博望遠鏡發現了水星的自轉周期、證明了中子星的存在，第一次直接觀測到小行星影像，輔助發現了第一批系外行星。
1974年，美國的拉塞爾·赫爾斯和約瑟夫·泰勒通過使用阿雷西博望遠鏡發現了第一個脈沖雙星系統。它由一顆脈沖星，PSR 1913+16，與一顆中子星構成，軌道周期很短，僅為7.75小時。軌道的偏心率為0.617。當兩顆子星相互靠得很近時，極強的引力輻射會導致它們的距離愈加靠近，軌道周期會逐漸變短。泰勒等人通過精確地測量射電脈沖雙星軌道周期的變化，間接證明了引力波的存在，驗證廣義相對論。赫爾斯和泰勒也因此獲得1993年的諾貝爾物理學獎。
1982年，美國天文物理學家和他的合作者利用阿雷西博射電望遠鏡發現了PSR B1937+21，它是人類歷史上發現的第一顆毫秒脈沖星。
1974年，阿雷西博望遠鏡向距離地球25,000光年的球狀星團M13發送了一串由1,679個二進制數字組成的訊號，稱為阿雷西博訊息。如果訊息被地外智慧生命所接收並正確解讀，會得到如右圖所示的訊息，從上到下依次為：用二進制表示的1-10十個數字、DNA所包含的化學元素序號、核苷酸的化學式、DNA的雙螺旋形狀、人的外形、太陽系的組成、望遠鏡的口徑和波長。向球狀星團M13發送訊息的原因是其中的恒星分布比較密集，被地外智慧生命接收的可能性較大。
阿雷西博射電望遠鏡因其外形壯觀等特點，曾被電影、電視劇和游戲等文創作品采為取景地。007系列黃金眼和電影《接觸未來》的部分場景就是在這里拍攝的。
阿雷西博天文臺的觀測數據為1999年開始的分散式運算項目SETI@home做出貢獻。
贊寧，俗姓高。吳越吳興郡德清（今屬浙江）人。
生於貞明五年（919年），先人是黃河流域的渤海郡人，隋末徙吳興郡清德縣。後唐天成年間贊寧在杭州祥符寺出家。後入天臺山受具足戒，先學四分律，精研三藏。後往靈隱寺，習南山律，旁通儒、道二家。文辭頗善，與人談論，辭辯縱橫，雖東方朔、張茂先亦不能過，人稱“律虎”。吳越武肅王時曾任監壇和兩浙僧統，賜號明義。
宋太祖賜贈紫衣。宋太宗徵他入汴京，于太平興國三年（978年）隨吳越王入朝，賜號“通慧大師”。太平興國初，奉詔編修《大宋僧史略》3卷，充右街副僧錄。太平興國七年（982年），又撰有《宋高僧傳》，仿梁代慧皎《高僧傳》和唐道宣《續高僧傳》體例，分十科，記載了從南北朝至宋朝年間，五百三十三人有傳，附見一百三十人。又記有三十八位高僧及其譯經成果。端拱元年（989年）成書，由弟子顯宗和智輪上呈宋太宗，上命僧錄司編入大藏流通。
淳化元年（990年）任左街講經首座，隔年任史館編修。淳化三年（992年）兼翰林館編修。至道元年（995年）掌管洛京（今河南洛陽）教門事。真宗咸平元年（998年），充右街僧錄。咸平三年（1000年）遷左街。咸平四年（1001年）卒，享年八十三。徽宗崇寧四年（1105年），加謚圓明。
歐陽修說：“吳僧贊寧，國初為僧錄，頗讀詩書，博覽強記，亦自能撰透，而辭辯縱橫，人莫能屈”。《皇朝類苑》卷五九說:“僧贊寧，有文學，洞古博物，著書數百卷。王元之（王禹偁），徐騎省（徐鉉），疑則就質焉，二公皆拜之”。《西湖高僧事略》等有傳。
森麻實道是香港一條道路，位於九龍九龍塘，西起根德道，東至窩打老道。森麻實道西段是單程路，兩方入口的車輛的方向是向內再到德雲道前往歌和老街離開。
森麻實道有很多婚紗店、長者院舍、住宅、學校、公司辦公室，其中以森麻實道的耀中分校最為著名。在上學繁忙時間森麻實道十分擠塞，因該學校的學生家長駕私家車到森麻實道接子女放學／上學。另外，森麻實道近根德道段在耀中中學前面有來往中國大陸的直通車巴士站，十分多中國遊客在行人路上。此外，森麻實道與根德道交界的行人路是著名的約人地點，該處交通方便，接近九龍塘站和九龍塘公共交通交匯處。
森麻實道以英國的森麻實郡命名。
越秀南客運站
越秀南客運站是廣州的一個已拆除的客運站，建於1950年。為一個國有汽車客運站，由廣州市長途汽車運輸公司負責管理運營，車站位於越秀區越秀南路東園橫路2號，站場占地面積12000多平方米，其中車場6200平方米，發車位26個。
客運站經營的線路遍達廣東省內多個地區和江西、江蘇、廣西等省外多個市縣，現已開通了香港、澳門、深圳、珠海、中山等多條直達快線。
越秀南客運站于2019年5月1日關閉。
六號線團一大廣場站A出口
《達夫尼與克羅伊》乃莫里斯·拉威爾根據同名音樂劇所作之芭蕾舞曲。該曲之芭蕾舞音樂，以古希臘詩人朗高斯的《達夫尼與克羅伊》全三場組成作品為基礎，並由俄羅斯芭蕾舞團於1912年在薩特蕾歌劇院作巴黎首演。而拉威爾本人亦從芭蕾舞音樂摘錄了一部分，改寫為第1號組曲與第2號組曲，並分別在1911年及1913年首演。
（1910年）
1909年，迪亞基勒夫帶領的俄羅斯芭蕾舞團在巴黎之表演取得重大的成功。為向著該成功進發，迪亞基勒夫遂委託新潮作曲家新作芭蕾舞音樂，拉威爾身在此列。據拉威爾所撰的信中提到，同年6月他已經跟芭蕾舞團老師商討關於該劇之大綱。寫作期間，拉威爾的音樂設計與委託方的要求有所捍格，拖延了整體進度。經過許多波折，作品在1912年4月5日完成。對於創作理念，拉威爾表示：
* 全曲—1912年6月8日，於巴黎薩特蕾歌劇院首演，由皮埃爾·蒙特指揮。由俄羅斯芭蕾舞團演出，其他成員包括米歇爾·弗金（排舞），雷昂·帕克斯特（美術及服裝），瓦斯拉夫·尼金斯基（飾達夫尼），達瑪拉·卡爾薩維納（飾克羅伊）。
* 第一組曲—1911年4月3日、嘉貝爾·佩爾尼指揮科倫管弦樂團。
* 日本首演（第二組曲）—1941年6月5日、約瑟夫·魯森斯道克指揮NHK交響樂團。
演出的反應不甚正面，拉威爾本人亦認為作品中音樂的部分更重於舞蹈，後來將之改寫為第1號、第2號管弦樂組曲（作品號M. 57a/b），又以第2號更受到好評。
《達芙尼與克羅伊》原本是朗高斯的田園牧歌式小說，描寫萊斯博斯島上，牧羊人達夫尼與牧羊女克羅伊的愛情故事，弗金與拉威爾共同編寫的本作，則是根據羅馬小說《達芙尼與克羅伊的田園故事》改編而成。
;第一部分：麵包神與眾美少女們之祭壇前
眾人向山河女神寧芙（Nymph）做舞蹈禮拜，期間達夫尼與追求者發生了衝突，雙方以克羅伊的芳心為籌碼進行比試，達夫尼獲勝。此時海盜來襲，克羅伊被擄，達夫尼因絕望而昏厥過去。在「夜曲」中，三尊河川女神的雕像化為人形，將達夫尼抬進洞裏，並向牧神潘（Pan）求救，這時遠處傳來人聲合唱。
;第二部分：海盜布魯艾希斯之陣營
此時，海盜們在巖島上跳著戰舞（Danse guerriere），慶祝勝利。首領布魯艾希斯（Bryaxis）命令俘虜克羅伊舞蹈以取悅眾人，克羅伊假意順從，欲趁勢脫逃，不過沒有成功。這時，天上降下一道刺眼的光芒，無法計數的山羊團團圍住海盜，巨大的潘神幻影出現，並怒目瞪視海盜們，布魯艾希斯見狀立即釋放了克羅伊。
;第三部分：祭壇前
達夫尼熟睡在河川女神的洞窟前，在破曉的牧羊人笛聲中，克羅伊被牧羊女簇擁前來，兩人重逢。事實上，牧神因愛慕河神西琳克絲（Syrinx），才答應了救援請求。而達、克正象徵著牧神、河神在現實中的結合。「默劇」一段，即達、克兩人詮釋牧神、河神的愛情故事。在最後的獻祭儀式上，達夫尼重立誓言，在「群舞」（Danse générale）中眾人共舞，故事迎來美好的結局。
全曲約50至55分鐘。
原作的樂隊編制如下：
** 長笛：2（其一兼第二短笛）
* 擊樂：鑼、風聲器、三角鐵、大鼓、小鼓、響板、鈴鼓、鋼片琴、古鈸、鈸、懸鈸、鐵琴
依照工具書《管弦樂作品手冊》指示，上述之配器可簡記為"=4 *3 =4 *4—4 4 3 1—tmp+8—2hp, cel—str"。
#黎明（Lever de jour）
#啞劇（Pantomime）
#群舞（Danse générale）
* 法國詩人柯克圖：「《達芙尼與克羅伊》吸引我們的地方，就是音樂中前所未有的組合，對我們而言，就像是隕石從遙不可解的行星那裏，墜落到我們心中一般。」
X Window  核心協議是X Window系統的基礎協議，它是一個以點陣圖顯示的網絡化視窗系統，用來在Unix、類Unix和其他作業系統上建立使用者圖形界面。X Window 系統基於主從式模型：單一伺服器控管硬體的輸出入，如螢幕、鍵盤和滑鼠；所有的應用程式都被視作客戶端，使用者之間透過伺服器來互動。互動部分由X Window核心協議來管理。還有其他與X Window系統有關的協議，有的建立在X Window核心協議之上的，有的是獨立的協議。
在X Window核心協議中，只會在網絡上以非同步方式傳送四種封包：請求、回應、事件和錯誤。請求是由客戶端傳送到伺服器，告之進行一些動作（例如建立一個視窗），並回傳以便持握的資料。回應是由伺服器回傳的若干資料。事件是由伺服器傳送的，其用來通知客戶端某些使用者的動作，或者發生了其他所關心的事件。錯誤是由伺服器傳送的封包，其用來通知客戶端，在處理其請求時，發生了一些錯誤。請求有可能產生回應、事件和錯誤；除此之外，協議並不要求封包中的特定指令要以網絡來傳送。還有其他對核心協議的擴充，這些擴充有自己的請求、回應、事件和錯誤。
X Window 源於1984年的麻省理工學院（目前所發佈的 X11 發表於1987年9月）。設計者鮑伯·斯凱夫勒（Bob Scheifler）和吉姆·杰提斯（Jim Gettys）早期對核心協議的原則是「機制，而非策略」，所以核心協議並未規定客戶端之間以及客戶端和使用者之間的互動界面規範。這部分則由其它的獨立規格所規範，如ICCCM、freedesktop.org規範，且可由所使用的特定組件工具包自動強制執行。
伺服器和客戶端之間的通訊，是由通道上的交換封包所完成。由客戶端建立連線，且由客戶端發送第一個封包。封包中包括將要使用的字節序、協議版本方面的資訊，以及客戶端期望伺服器使用的認證種類。伺服器以回傳封包來答覆，封包中陳述接受或拒絕連線，或要求進一步的驗證。如果接受連線，接受封包內會包含客戶端接下來和伺服器互動所需的資料。
客戶端和伺服器之間的互動範例。
# 請求：客戶端請求伺服器的資訊，或者請求伺服器執行一個動作。
# 回應：伺服器回應請求。但並非所有的請求都會產生回應。
# 事件：伺服器傳送事件給客戶端。如：鍵盤或滑鼠的輸入，或移動、調整、顯示視窗等。
# 錯誤：如果請求無效時，伺服器會傳送一個錯誤封包。因為請求是以排隊方式處理，所以經由請求所產生的錯誤封包，並不會立即傳送出去。
請求和回應封包可以有各種長度，事件和錯誤封包的長度則固定是32位元組。
請求封包的編號順序是以伺服器的接收為順序：來自客戶端的第一個請求編號為 1、第二個編號為 2，依此類推。請求的序列編號中最小的有效16位元，包含在由請求所產生的回應和錯誤封包之中，如果有的話。它們也包含在事件封包中，以指出伺服器正在處理或是剛剛完成的請求序列編號。
在X Window系統以及各種圖形化使用者界面中，視窗即為一個頂層視窗。視窗也用來指視窗內部的視窗，這類視窗是父視窗的子視窗。圖形化元件，如按鈕、選單、圖示等等，都是使用視窗來實現的。
客戶端可請求建立一個視窗。更嚴謹的說，客戶端可請求建立現存視窗的子視窗。所以客戶端所建立的視窗，皆以樹狀結構組織（階層結構）。樹狀結構的根即為根視窗，根視窗是伺服器在啟動時，所自動建立的特殊視窗。其餘視窗都是根視窗的子視窗，頂層視窗就是根視窗下的第一個子視窗。如圖所見，根視窗和螢幕同等大小，且在其餘視窗的後面（被子視窗遮蓋住）。
視窗裡的內容並非在所有時候都能顯示出來。更精確地說，在視窗移動、調整大小、被其他視窗遮蓋、部分或整個視窗不可見時，視窗裡的內容就有可能會被銷毀。更精確地說，如果 X 伺服器無法維護視窗內容的後備存放區（backing store）時，這些內容就會遺失。客戶端可請求為視窗進行維護的後備存放區，但伺服器沒有義務要這樣做。因此，客戶端不可假設已得到後備存放區的維護。若視窗有一部分未指出內容時，就會傳送一個事件，通知客戶端重繪那部分內容。
每個視窗都關聯一組屬性值（Attribute），如視窗的幾何性質（大小和位置）、背景圖、是否請求了後備存放區等等。協議中還包含用來給客戶端檢閱和改變視窗屬性值的請求。
視窗可以是 InputOutput（輸出／輸入）或 InputOnly（僅輸入）。前者是顯示在螢幕上用於繪圖的視窗，而後者並不顯示在螢幕上，僅用來接受輸入。
FVWM視窗的結構。中央的大塊白色區域是由客戶端應用程式所建立的視窗。
平常可看到視窗周圍的裝飾性框架和標題列（可能含有按鈕），是由視窗管理器所建立的視窗，而非客戶端所建立的。視窗管理器也處理與元件有關的輸入，例如當使用者點擊並拖曳視窗的邊框時，便會調整視窗大小。客戶端所建立的視窗，通常可以忽略視窗管理器所帶來的變化。還有一個改變必須注意，那就是改變親屬關係的視窗管理器，幾乎所有新式的視窗管理器，都會將頂層視窗的親屬關係改變到一個視窗（不是根視窗）裡去。從核心協議的角度來看，視窗管理器是一個客戶端，與其他的應用程式沒有區別。
關於視窗的資料，可執行 xwininfo 程式來取得。加上 -tree命令列參數，程式便會顯示子視窗的樹狀結構，連同識別子和幾何性質資料一起顯示。
圖形映射（pixmap）是記憶體中可用來繪圖的區域。與視窗不同，圖形映射的內容並不會自動顯示在螢幕上。不過圖形映射的內容（或部分內容）可轉換到視窗上，反之亦然。這就讓雙緩衝得以實作。大部分可在視窗上完成的圖形化操作，也可以圖形映射完成。
視窗和圖形映射被統稱為可繪區（drawable），且其資料內容都保留在伺服器上。客戶端可請求從伺服器上，將可繪區的內容轉換到客戶端，反之亦然。
客戶端可請求很多種圖形運算，如清空一塊區域、複製一塊區域到另一處，繪製一個點、線、矩形和文字。對清空而言，所有運算都有可能用在可繪區上（視窗和圖形映射）。
圖形脈絡（graphic context）包括了對圖形運算的大部分請求，圖形脈絡是一種結構，包含有圖形運算的參數。圖形脈絡包含前景色、背景色、文字的字體，以及各種圖形參數。當請求圖形運算時，客戶端就包含一個圖形脈絡。很明顯的，並非所有的圖形脈絡參數都會參與運算：例如，字體對於直線的繪製不產生作用。
核心協議規格使用了伺服器側的字體。如字體是以檔案形式存放，伺服器經由本機的檔案系統直接存取，或經由網絡從字體伺服器存取。客戶端可向伺服器請求有效的字體列表，且可請求伺服器載入（沒有的話）或卸載（客戶端不再需要的話）字體。客戶端可請求關於字體的資訊（例如，ascent 字體），並以指定的字體來繪製指定的字串。
xfontsel 程式可讓使用者檢視字體的標記。
在X Window核心協議的層次上，字體的名稱可以是任意的字串。X 邏輯字體描述協定規範了如何根據字體的屬性來命名。這些協定也規範了可附屬於字體的選用屬性之值（value）。
xlsfonts 程式可輸出存放在伺服器上的字體列表。xfontsel 程式可顯示字體的標記，並讓使用者選取字體的名稱，以在其他視窗中貼上。
目前已不再重視伺服器側字體的使用，而轉向客戶端側字體的使用。例如，藉由支援Xft或cairo程式庫，以及XRender擴充，改由客戶端（而非伺服器）繪製字體。客戶端側字體在核心協議中尚未給出規範。
所有關於視窗的資料、圖形映射、字體等等，皆存放在伺服器上。客戶端知道那些物件的識別子，和伺服器互動時，物件以整數為名稱。例如，當客戶端希望建立一個視窗時，便指定一個識別子，並請求伺服器建立一個視窗。伺服器會建立一個視窗，並與指定的識別子關聯。稍後客戶端可使用這個識別子進行請求，例如在視窗上畫上一個字串。以下存在於伺服器上的物件，客戶端可藉由數值型的識別子得知：
* 色彩映射（Colormap）（即顏色表，稍後描述）
* 圖形脈絡（Graphic context）
這些物件就稱作資源。當客戶端請求建立某一種資源時，同時也為資源指定了一個識別子。例如，為了建立一個新視窗，客戶端指定了視窗的屬性值（親屬關係、寬、高等等）和識別子，最後識別子會和視窗關聯。
識別子是三個最高有效位為0的32位元整數。每一個客戶端都有一組自己的識別子，其可用來建立新的資源。這組識別子是由伺服器以包含在接受封包（傳送給客戶端的封包，通知已接受連線）中的兩個整數所指定的。客戶端以避免衝突的方式選取識別子：在視窗、圖形映射、字體、色彩映射、圖形脈絡之中的兩個物件，不可具有相同的識別子。
資源一經建立，其識別子就用於客戶端向伺服器請求與之有關的運算。部分運算會影響特定的資源（例如，請求移動視窗），其他的則要求存放在伺服器上的資源資料（例如，請求視窗的屬性值）。
識別子在伺服器上是獨一無二的，在多個客戶端之間也不例外。例如，即使是由兩個不同客戶端所建立的視窗，也不會同時具有相同的識別子。即使某個物件不是由自己的客戶端所建立的，只要指定相對應的識別子，就可存取另一個客戶端所建立的任何物件。
連線到同一伺服器的兩個客戶端，對同一資源可使用同一識別子。例如，若客戶端建立一個 0x1e00021 識別子的視窗，並傳送數值 0x1e00021 給其他的應用程式（透過任何有效的手法。例如，把數值存放在檔案裡，且這個檔案可讓其他的應用程式輕易存取），其他的應用程式即可對同一視窗進行操作。這個例子是來自X Window版本的Ghostview：程式建立一個子視窗，在環境變數中存放其識別子，並呼叫Ghostscript；程式繪製PostScript檔案的內容，以顯示在這個視窗上。
當建立資源的客戶端關閉與伺服器的連線時，資源就會正常的銷毀。不過在關閉連線之前，客戶端可以請求伺服器不要銷毀資源。
事件是由伺服器傳送到客戶端用以通訊的封包，傳送一些客戶端可能感興趣的事情。例如，當使用者按下按鍵或點擊滑鼠時，便會傳送一個事件。事件不只用於輸入：例如，傳送的事件表明特定視窗建立了新的子視窗。
每一個事件都會涉及到視窗。例如，當使用者的鼠標在視窗之內並點擊時，這個事件就會涉及到那個視窗。事件封包中含有那個視窗的識別子。
客戶端可以請求伺服器傳送事件給另一個客戶端，這可用於客戶端之間的通訊。例如，當客戶端請求目前所選取的文字時，就會傳送事件給客戶端，以處理目前所持有的選取內容。
當再度觀看內容已被銷毀的區域時，有可能會傳送 Expose（顯露）事件。而且在某些情況下，視窗的內容可能會被銷毀。例如，當視窗被其他視窗遮蓋住，且伺服器沒有維護後備存放區時。此時伺服器會產生一個 Expose 事件，以通知客戶端重繪視窗已消失的部分。
事件的範例：當在視窗上按下按鍵時，會產生事件給客戶端（取決於視窗的事件掩碼，客戶端可以改變事件掩碼）。
大部分的事件只會在客戶端預先表示關心時才會傳送。因為客戶端可能只需要關心某類型的事件。例如，客戶端可能會關心關於鍵盤的事件，但卻不關心關於滑鼠的事件。即使在客戶端並未明確請求的情況下，某幾類事件也會不斷的傳送給客戶端。
客戶端可以設置視窗的屬性值（attribute），以指明想要接收哪些事件。例如，當視窗的內容已銷毀時，為重繪其內容，客戶端就必須接收 Expose 事件，以通知視窗需要再次重繪。客戶端要能接收到 Expose 事件，就要預先指明它所關心的事件，這部分可以適當設置視窗屬性值的事件掩碼來完成。
不同的客戶端可以請求同一視窗的事件。甚至可對同一視窗設置不同的事件掩碼。例如，某個客戶端可以只對視窗請求鍵盤事件，而另一個客戶端只對視窗請求滑鼠事件。這是可以的，因為伺服器會為每一個客戶端維護事件掩碼，而且是每一個視窗都維護一份獨立的事件掩碼。不過偶爾也有某幾類事件，只能由一個客戶端選擇。特別是，這類事件回報滑鼠按鈕的點擊，且部分變化會涉及到視窗管理器。
xev 程式顯示視窗所涉及到的事件。xev -id WID 可對識別子為 WID 的視窗要求所有可能的事件，並將其輸出。
以下是伺服器和程式之間的互動範例，這個程式會建立一個黑框視窗，按下按鍵後結束。在本例中，伺服器並未傳送任何回應，因為客戶端的請求並不產生回應。這些請求有可能產生錯誤。
# 客戶端開通與伺服器的連線，並傳送初始化封包，來指定所要使用的位元順序。
# 伺服器接受連線（本例中不涉及驗證）並傳送適當的封包。這些封包含有其他的資訊，如根視窗的識別子（例如，0x0000002b），以及客戶端可建立哪些識別子。
# 客戶端請求以 0x00200000 識別子建立一個預設的圖形脈絡（此一請求如同本例中的其餘請求，並不會產生來自伺服器的回應）。
# 客戶端請求伺服器以 0x00200001 識別子、大小 200x200、位置 (10,10) 等等，來建立一個頂層視窗（這部分指定以根視窗 0x0000002b 為父視窗）。
# 客戶端請求改變視窗 0x00200001 的屬性值（attribute），規定視窗要接收 Expose（顯露）和 KeyPress（按鍵）事件。
# 客戶端請求映射（顯示在螢幕上）視窗 0x00200001。
# 當視窗可見，且必須繪出其內容時，伺服器傳給客戶端一個 Expose（顯露）事件。
# 客戶端對事件做出反應，請求繪製一個方框，它是透過傳送與視窗 0x00200001 和圖形脈絡 0x00200000 一起的 PolyFillRectangle 請求來達成。
如果視窗被其他視窗遮蓋住，且再次顯露出來時，又剛好沒有這部分的備存時：
# 伺服器傳送另一種 Expose（顯露）事件，告知客戶端必須再次重繪視窗。
# 客戶端透過傳送 PolyFillRectangle 請求的方式重繪視窗。
如果按下按鍵：
# 伺服器傳給客戶端一個 KeyPress（按鍵）事件，通知它使用者按下按鍵了。
# 客戶端作出適當的反應（本例是結束程式）。
在協議層次裡，顏色使用32位元無負號整數來表示，稱為像素值。以下因素會影響顏色的顯示：
# 色彩深度
# 色彩映射（colormap），即含有紅、綠、藍強度值的表。
# 視覺類型（visual type），指明表如何用來表示顏色。
在最簡單的情況下，色彩映射是一種每一項都含有RGB三值的表。像素值 x 所表示的顏色，就包含在表中第 x 項。如果客戶端可以改變色彩映射的內容，那這種表示法就以偽彩色（PseudoColor）視覺分類（visual class）來標識。視覺分類中的靜態色（StaticColor）與偽彩色類似，只不過客戶端不能修改色彩映射的內容。
在此總計有六種可能的視覺分類，每一種都使用不同的方式來表示 RGB 像素值。PseudoColor 和 StaticColor 即其中兩種。GrayScale 和 StaticGray 是另外的兩種，其中最主要的差異是灰階漸層的使用。
剩下的兩種視覺分類和前述的差異在於，將像素值分成三個部分，並為紅、綠、藍的強度使用了三個獨立的表。並根據這個表來表示顏色，如下流程將像素值轉換成RGB色：
# 將像素值視為連續的位元序列
# 將位元序列分成三個部分
# 將每一個部分視為整數、並作為索引，以在這三個獨立的表中尋找到值。
這個機制需要以三個獨立的表組成色彩映射，三個原色各一個表。轉換以後仍是強度值的三聯色。使用這個表示法的視覺分類有 DirectColor 和 TrueColor，其中的差異是客戶端不能修改後者的色彩映射。
以上六種以像素值表示顏色的機制，都需要附加一些參數來運作。這些參數可統合為視覺類型，其包含一個視覺分類和其他參數以表示顏色。每一個伺服器都有一組固定的視覺類型，每一個類型都與數值型的識別子關聯。其識別子是32位元無負號整數，和資源或元素的識別子沒有什麼不同。
當接受來自客戶端的連線時，伺服器所傳送的接受封包裡含有區塊序列，每一個區塊都包含有關於某一個單一螢幕的資訊。就每一個螢幕而言，相關區塊包含著其他區塊的清單，每一個都涉及了螢幕所支援的色彩深度。就每一個螢幕所支緩的色度深度而言，這個清單中又包含視覺類型的清單。結果，每一個螢幕就關聯著各種合適的色彩深度，而且每一個螢幕的每一個色彩深度都關聯著各種合適的視覺類型。一個給定的視覺類型可用於更多的螢幕和各種不同的色彩深度。
就每一個視覺類型而言，接受封包中還包含它的識別子和它所包含的實際參數（視覺分類等），客戶端存放這些資訊，因為之後就不能再請求。此外，客戶端不能改變或建立新的視覺類型。建立新視窗的請求中，還包含有色彩深度和視覺類型的識別子，以此用來表示視窗的顏色。
色彩映射和控制螢幕的硬體（即繪圖卡）是否使用調色盤（palette）沒有關係。調色盤是一個表，也是用來表示顏色的。即使硬體並不使用調色盤，伺服器也能使用色彩映射。當硬體使用調色盤時，就只能安裝相當受限的少許色彩映射。更精確地說，當硬體根據色彩映射來顯示顏色時，就可以說是安裝了色彩映射。客戶端可請求伺服器安裝一個色彩映射。不過需要將另一個色彩映射解除安裝：其影響是視窗如果使用了解除安裝的色彩映射，就不能顯示正確的顏色，而出現怪異顏色的畫面。這個問題可以用標準色彩映射來解決，標準色彩映射是像素值和顏色之間關聯恆定的色彩映射。由於有這一性質，就可讓不同的應用程式使用標準色彩映射。
色彩映射的建立由ICCCM協定管理。標準色彩映射由ICCCM和Xlib規格管理。
元素（Atoms）是用來表示字串的32位元整數。本協議的設計者之所以引入元素，是為了以簡短、大小恆定的方式表示字串：由於字串可以是任意的長度，而元素總是32位元整數。某些封包可能會多次傳送相同的字串，元素的簡短性可以削減指令所使用的封包長度，進而增進網絡的使用效率。大小恆定的元素有利於大小恆為32位元組的事件：大小恆定的封包可以包含元素，卻不能包含過長的字串。
更嚴謹的說，元素是存放在伺服器上的字串的識別子，相當於資源的識別子（視窗、圖形映射等），但仍有兩個不同點。首先，元素的識別子是由伺服器選擇的，而非客戶端。換句話說，當客戶端請求建立一個新的元素時，其僅僅傳送字串給伺服器存放，而非字串的識別子；元素的識別子是由伺服器選擇，並回傳給客戶端作為回應。其次，資源和元素之間的重大差異是，元素並未與客戶端相連繫。元素一經建立，就能一直存留至伺服器結束或重置（此非資源的預設行為）。
元素是識別子，所以也是獨一無二的。不過元素和資源的識別子可以相一致。與元素關聯的字串稱作元素名。元素的名稱一經建立就不能再更改，而且不能有兩個相同名稱的元素。故一般以元素的內容作為元素的名稱：「元素 ABCD」意謂著，或更精確地說，「這個元素關聯的字串是 ABCD」或「元素的名稱是 ABCD」。客戶端可以請求建立新的元素，且可請求指定字串的元素（識別子）。某些元素已預先定義（由伺服器以特定的識別子和字串所建立）。
元素運用於多個目的，主要與連接到同一伺服器的不同客戶端之間有關。特別是，元素用於與視窗屬性的關聯，以下詳述。
所有存在於伺服器上的元素列表，可使用 xlsatoms 程式輸出。尤其這個程式可以元素的名稱（元素所關聯的字串）列出每一個元素（識別子是一串數字）。
每一個視窗都有一組預先定義的屬性值（Attribute）和屬性（Property），並存放在伺服器上，客戶端可以適當的請求方式取存。屬性值是有關視窗方面的資料，如視窗的大小、位置、背景色等等。屬性則是附屬於視窗上的資料片斷。與屬性值相反，屬性在X Window核心協議的層次中並沒有其他含意。客戶端可在視窗的屬性中存放屬性值資料。
屬性是以名稱、類型和值來描述，屬性相當於指令式程式語言的變數，應用程式可以指定名稱、類型和值來建立新的屬性。屬性和視窗關聯：兩個相同名稱的屬性可存在於兩個不同的視窗，且可具有不同的類型和值。
屬性的名稱、類型和值皆為字串；更精確地說就是元素，客戶端可藉由識別字，以存取存放在伺服器上的字串。客戶端應用程式可以元素的識別子（含有屬性的名稱）存取特定的屬性。
屬性大多用於客戶端之間的通訊。例如，名稱為 WM_NAME（屬性名稱就是元素所關聯的字串 "WM_NAME"）的屬性，是用來存放視窗的名稱；視窗管理器通常會讀取這個屬性，並在視窗頂部顯示名稱。
某些客戶端之間的通訊也使用了根視窗的屬性。例如，根據freedesktop視窗管理器規格視窗管理器應該在根視窗的 _NET_ACTIVE_WINDOW 屬性名中存放目前有效（active）視窗的識別子。X資源所含有的程式參數，同樣也是存放在根視窗的屬性裡；藉由這個方式，即使分別執行在不同電腦上，所有客戶端仍可存取到那些參數。
xprop 程式可輸出指定視窗的屬性，xprop -root 則可輸出根視窗每一個屬性的名稱、類型和值。
這顆鍵永遠會產生相同的鍵碼，但 /、7、{ 這些符號是和三個不同的鍵符關聯。
在X Window系統中，鍵盤上的每一個物理按鍵都關聯有 8～255 之間的號碼，這些號碼就稱作鍵碼（keycode）。一個鍵碼僅僅標識一個按鍵，而非特定的字元或功能鍵（如「Page Up」）。字元或功能鍵則由鍵符來標識。鍵碼僅僅取決於實際按下的按鍵，鍵符則可取決於按下的 Shift 鍵或其他的修飾鍵。
當按下或放開按鍵時，伺服器會傳送 KeyPress 或 KeyRelease 的事件類型給適當的客戶端。這些事件包含：
# 按下按鍵所產生的鍵碼。
# 修飾鍵（Shift、Control等）和滑鼠按鍵當下的狀態。
鍵碼如何轉換成鍵符。
因此伺服器傳送鍵碼和修飾狀態，而無須嘗試將其轉成特定的字元，這部份的轉換工作由客戶端自己的協定來完成。例如，客戶端可能接收到一個事件，而這個事件表示已按下「a」鍵，且 Shift 修飾鍵也已按下，客戶端（不是伺服器）就會把這個事件關聯為「A」。
客戶端完成鍵碼至鍵符的轉換以後，表示其關聯的表就由伺服器來維護，並將表集中存放在所有客戶端都存取得到的地方。客戶端只需請求映射，並使用它對鍵碼和其修飾鍵域解碼成鍵符。客戶端也可以任意改變此一映射。
當按下修飾鍵時，就會改變另一個按鍵的解碼。常見的修飾鍵有Shift鍵：平常會產生小寫字母「a」的 a 鍵和 Shift 鍵一起按下時，就會產生一個大寫字母「A」。其他常見的修飾鍵還有「Control」、「Alt」和「Meta」。
X 伺服器最多可用八個修飾鍵，不過每個修飾鍵可關聯一個以上的按鍵。例如，很多鍵盤有兩個「Shift」鍵（一左一右）。按下這兩顆按鍵時，會產生兩個不同的鍵碼，不過 X 伺服器會把那兩者都關聯到「Shift」修飾鍵。
X 伺服器為八個修飾鍵維護一份可以認出修飾鍵的鍵碼清單。舉個例子，如果清單中的第一個修飾鍵（「Shift」修飾鍵）包含鍵碼 0x37，然後有某個按鍵會產生鍵碼 0x37，X 伺服器就認為那個按鍵是 Shift 鍵。
修飾鍵映射的清單由 X 伺服器維護，也可以讓所有的客戶端修改。例如，客戶端可以請求將「F1 鍵」加到「Shift」修飾鍵的清單中。從此，這顆按鍵的效果就如同 Shift 鍵一樣，不過 F1 仍會產生本身的鍵碼。結果，F1 仍做它以前所做的（例如，按下 F1 時，會開啟說明視窗），不過又和 Shift 一樣（在文字編輯器裡，按下「a」和 F1，就會打出「A」）。
X 伺服器也為滑鼠按鍵維護並使用修飾鍵映射，不過只能改變順序。其最大的用處就是為左撇子調換左右兩邊的按鍵。
xmodmap 程式可以顯示並改變按鍵、修飾鍵和滑鼠按鍵的映射。
截取（grab）即所有鍵盤或滑鼠的事件，都傳送到單一客戶端上。客戶端可以請求鍵盤、滑鼠或兩者的截取：如果伺服器履行此一請求，所有鍵盤和滑鼠的事件，都會傳送到截取中客戶端，直到解除截取為止。此時，其他的客戶端將接收不到這些事件。
請求截取時，客戶端會指定一個截取視窗：所有事件都會傳送到截取中客戶端，彷彿和截取視窗相關。不過其他的客戶端接收不到事件，即使是在截取視窗中進行選取。在此有兩種截取：
;主動式:立即進行截取。
;被動式:只在按下預先指定的按鍵（或滑鼠按鍵）時才會進行截取，並在放開時結束。
如果游標或鍵盤是被凍結的話，其所產生的事件將會在佇列上被攔截。如果是可截取的話，其事件會轉運給截取的客戶端，而不是原本可接收到事件的視窗。游標事件可藉由事件掩碼加以排除、拋棄。
客戶端可截取鍵盤、游標或兩者。截取請求中也可包含用來凍結鍵盤或滑鼠的請求。截取和凍截的不同處在於，截取改變事件的接收者，而凍結只是完全停止遞送。當裝置凍結時，它所產生的事件會存放在佇列中，並在結束凍結時照常遞送。
對於游標事件來說，額外的參數會影響到事件的遞送：事件掩碼指定要遞送或拋棄哪些類型的事件。
截取請求中還包含一組字段，字段用來在還沒建立截取之前，就指明傳送給截取中客戶端的事件將要發生什麼。更精確地說，客戶端可請求它們照常傳送或進行截取。這兩種情況和它們所表現出來的有所不同。例如，在第一個視窗上正常接收鍵盤事件的客戶端，可能會透過第二個視窗來請求截取鍵盤。事件將會正常傳送給第一個視窗，而未必重新導向給截取視窗，這取決於截取請求裡所下的參數。
客戶端也可請求截取整個伺服器。在這種情況下，伺服器將不會處理任何請求，除了來自截取中客戶端的請求以外。
還有其他的請求和事件，有一種請求是有關視窗之間的親屬關係：客戶端可請求改變視窗的父視窗，或請求關於父視窗的資訊。其他的請求則是關於選取，這部分大多由其他的協議來管理。還有的請求是關於輸入焦點和游標的形狀。客戶端也可請求將資源（視窗、圖形映射等等）的所有者殺死，這會使伺服器終止和那個所有者的連線。最後，客戶端還可傳送空運算請求給伺服器。
shape extension可讓 oclock 程式建立圓形視窗。
X Window 核心協議被設計成可擴充。核心協議指定一個機制用來查詢可用的擴充，以及如何產生擴充的請求、事件和錯誤封包。
更精確地說，客戶溯可以請求所有可用的擴充的清單，擴充的封包相當於核心協議的封包。核心協議指定請求、事件和錯誤封包要包含一個指明其類型的整數（例如，建立一個新視窗的請求是號碼 1）。一部分範圍的整數已保留給擴充。
在客戶端和伺服器剛開始建立連線的時候，伺服器的回應可以是接受、拒絕或要求驗證。驗證請求包含要使用的驗證方法的名稱。核心協議並不規範驗證程序，這部分要看所使用的驗證類型，並在伺服器傳送接受或拒絕封包之後結束。