先日出先で桃色の花が目に入って
桜？いやいやいやいやまだ季節が早い？梅？桃？なんていいながら近寄ってみたところ「河津桜」と表記がありました。
一足早く1月から2月にかけて咲く桜とのこと。
先週はやはり出先で虹を見ました。
足元まではっきりしている虹をみるなんて何年ぶりだろう。
ちょっと明るい気分にもなれたし
ブログのネタにもなっていただこうって思ったのですが
これだけで引き延ばすのはむつかしいですね。
伊那谷は山間にあるため、とても水の綺麗な場所です。そのため、醸造所や養命酒の工場など綺麗な水がかかせない施設も多く建っています。
そんな伊那谷は食べ物も非常に美味しく、馬刺しや伊那谷名物のローメンなどの名物が有名です。もし伊那谷を訪れることがあったらこれらの名物を食べてみるのもいいかもしれませんね。
さらに、伊那谷を訪れた際にはお土産として伊那谷銘菓もお勧めです。
まずは、菓子庵石川 さんの「ちぃずくっきぃ」
伊那の銘菓 ちぃずくっきぃ
次も菓子庵石川 さんで「まろんぱい」
伊那の銘菓 まろんぱい
こちらは あかはね さんの「桜チーズサブレ」
伊那の銘菓 桜チーズサブレ
桜の花びらを模したかわいい菓子です。サクッとした歯ごたえと口に広がるチーズの香りがたまらない一品。
同じく あかはね さんの「梅えずら」
伊那の銘菓 梅えずら
梅の練り込まれた白あんの中に甘酸っぱい梅の実が包まれているお菓子です。白あんの甘みの中に梅の実の酸味が効いているため、しつこくなくさっぱりとした味わいがとても上品です。
伊那の銘菓
今回ご紹介したもの以外にも伊那谷にはお土産にふさわしい銘菓がたくさんんあります。みなさんも伊那谷に訪れた際には是非お求めください。
2020年2月20日に XML/HTML 自動組版ソフトのベストセラー『AH Formatter』をバージョンアップした『AH Formatter V7.0』を公開しました。
『AH Formatter V7.0』では、欧文組版における行分割処理の改良、BIDI処理の改良、GUI の改良、
ドロップキャップ・PDF 2.0 出力・PDF/X-4p 出力・Adobe Fonts・WebP への対応など
盛りだくさんです。
詳しくは「ニュースリリース」に記載しておりますので、是非ご覧ください。
2/27追記：3/6日に開催を予定しておりました「自動組版エンジン【AH Formatter V7】セミナー 」は新型コロナウイルス感染症に関わる状況の急激な変化を鑑み、開催を中止いたします。
大容量・多言語データに最適な自動組版ソフト【AH Formatter】が、8年振りのメジャーバージョンアップを行いました。その新機能の説明と最新の海外動向、事例紹介、及びDITAに関する簡単なセミナーを行います。
【AH Formatter】は、独自開発した PDF出力エンジンで、
アクセシブルなタグ付きPDF や印刷用の PDF/X、長期保存用の PDF/A などさまざまな PDF形式の出力ができます。
| AH Formatter 20年の歩み | ||
アンテナハウス 小林 徳滋
|
| PDFもDTPデータもハイブリッドで提供可能 自動組版クラウドサービス「DOT3」でのFormatter利用事例 | |||
| 株式会社 ニューキャスト 川原 正隆 様 | |||
| 求人・クーポン・住宅などの情報誌からメーカーや商社発行のカタログなど様々な商業印刷物をクラウド上のFormatter（ASPライセンス）でPDF生成しています。 また、同じデータをInDesignで編集可能なIDMLにも変換してハイブリッドな提供を実現している事例をご紹介します。
|
| DITAの「コンテンツ再利用」について |
| アンテナハウス 小林 具典 |
| DITAの大きな目標のひとつである「コンテンツ再利用」の仕組みを説明します。 またこの仕組みを上手に利用することにどういうメリットがあるのかにも触れます。 |
| 開始 | 終了 | |
| 13:15 | 13:30 | 受付開始 |
| 13:30 | 13:35 | ご挨 |
| 13:35 | 14:05 | AH Formatter 20年の歩み |
| 14:05 | 14:35 | AH Formatter V7.0 新機能紹介 |
| 14:35 | 15:15 | 事例紹介 ニューキャスト様 |
| 15:25 | 15:55 | AH Formatter 海外動向 |
| 15:55 | 16:25 | DITAの「コンテンツ再利用」について |
| 16:25 | 16:45 | 質疑応答 |
| 日時 | 2020年3月6日（金）13：15～16：45 | |
| 会場 | 関東ITソフトウェア健康保険組合 1FA | |
| 住所 | 東京都新宿区百人町2丁目27-6 |
参加登録は次のページで受け付けております。
ちょっと、仕事プログラムで1つのファイルが肥大化傾向があって、「Java クラス 分割」というキーワードでググってみた。
そもそもJavaってのはクラスを分割して書けないという融通の利かない言語で、割と常識的なこととか初心者向けのことを書いてるページが並ぶ。
『何をクラス分割の指針とすべきか』（https://iwamototakashi.hatenadiary.jp/entry/20090530/p1）に書いてあるLCOM (Lack of Cohesion in Methods) ってのが面白い。
元ネタはITmedia。
で、常々失敗したOOPプログラムに接していると、いかに変数を減らすか、いかにインスタンスを減らすかばかり考えているわけですよ、最近は。
で、先程のページの
『ちなみにインスタンス変数のないクラスは、ほぼ不要であると個人的には思っています。そのようなクラスは、
スタティックメソッドの集まりになるのでしょうが：Static methods are procedural! In OO language stick to OO. And as far as Math.abs(-5) goes, I think Java got it wrong.
I really want to write -5.abs(). Ruby got that one right. Static Methods are Death to Testabilityという Miško Hevery 氏の意見(http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/)に私は賛成です。』
なんてことを読んじゃうと、喧嘩売ってんのかと思う。いやまぁ、勝手に読んでるのは私ですが。10年も前の記事なんで、今でも同じ考えとは限らないなと思う。
例に上がってるMath.abs(-5)の書き方は重要ですよ。これ、どっからでも呼べますから。
色々考えて最近はDBのテーブルアクセスは全部スタティックメソッドにしてる。SampleTbl.Record rec = SampleTbl.getById(String id)って感じ。
OOP的な意味では全てファクトリですよ。ファクトリしかないのだから全部スタティックメソッド。
レコードは普通にクラスなんで好きにすればいいけど、本質的にはget/setしかない。
で、SampleTbl.getByIdはコード上どこからでも好きに呼べるのが重要。誰がDBアクセスインスタンスを持ってるかとか気にしない。
そういうのは基本戦略としてメソッド内に封じ込める。
まぁ、スタティックメソッドの集まりに価値のある応用もあるってこと。
あと、Math.abs(-5)を先に作って、-5.abs()は最終的にMath.abs(-5)を呼ぶというような実装もよくやる。逆ではない。
私も関数型言語に触れるまではスタティックメソッドを活用しようとはあまり思わなかった。この10年でだいぶコードの書き方が変わった。
三つの選択肢のどれかが当り。出題者はどれが当りか知っている。
回答者が選択した一つ以外の残り二つから出題者がはずれを選んで開ける。
さて、回答者は選択を維持するか変えるかどっちが有利か。これがモンティ・ホール問題。
モンティ・ホール問題が納得いかなくて、なるべく愚直にプログラムを書いてみようかと思い、
具体的にどう書こうかと考えてる間に納得してしまった。でもPythonで一応愚直に書いてみた。
「モンティ・ホール問題 プログラム」でググると似たような愚直なプログラムを書いた人は結構いるので掲載はしない。
最近Ubuntuを使いにくいなぁと思っていた。問題はGUIで上にバッテリーステータスや日付表示されるパネルのフォントサイズを変更できなかったからだ。
UbuntuがUnityをやめてGNOME 3に移行したことで、どうやって設定変更したら良いのかわからなくなったのだ。VAIO Pro 11は割と画面解像度が高いので、
そのままでは非常に小さい文字しか表示されない。FirefoxやTerminalは個別にフォントサイズを大きくできるのでいいのだが、パネルに表示される日付やらバッテリー残量やらアプリのメニューやらは小さいまま。Unityの頃はディスプレイ画面のdpiを指定することで全体の文字サイズを調整できたのだがそういった機能はなくなったようだ。Kotlinのお試しのためVAIOを活用しようかなと思い、ちょっとググる。
GNOME 3のExtensionでUser Themesを有効にする。~/.themesに独自テーマのディレクトリを用意し、~/.themes/<テーマ名>/gnome-shell/gnome-shell.cssを作る。
# gnome-shell.css
stage {
font-size: 18pt;
}Tweaksの[外観 – テーマ – GNOME Shell]で上記<テーマ名>を選ぶ。
これでようやくGNOME 3のパネルの文字が読めるようになる。ともかく老眼には厳しい話だ。
GNOME 3のウィンドウマネージャはMutterというそうだ。dconf-editorでorg.gnome.mutterに幾つか設定がある。
edge-tilingをオフにすると、Ubuntu 18.04でかなりイライラさせられる「ウィンドウを移動させたいだけなのに、
上に持っていくと最大サイズにされてしまう」という問題が解消する。あぁ、嬉しい。
Ubuntuを起動したまま放置すると例えば30分でブランクスクリーンになるように設定している。
マウスを動かしたりするとブランクスクリーンを解除するのだが、Unityの頃にはなかった変な画面になっている。
真ん中にドカンと時計が表示されるロック画面とは違う謎画面。この画面の解除にはキーボード入力を要求する。いや、正確ではないな。
マウスで解除する方法はあるにはあるが、タッチスクリーンにおけるスワイプアップ相当の動きをマウスで行う必要がある。
これ決めた人は明らかに変。どう考えてもおかしい。キーボードくらい押せばいいとか思うでしょ。マシンを落とす（パワーオフにする）にはメニューから電源オフをするのが正しい手順で、
キーボードがなくてもちゃんと行える。逆に、キーボードに電源ボタンがない限り、キーボードだけでマシンを落とす方法はUIには用意されていない。
ノートパソコンはキーボードの近くに電源ボタンがあるからマシだが、デスクトップ機の電源を落とすのに電源ボタンを押すなんてことは普通しない。
という状況にも拘わらずキーボードを要求する、GNOMEは。とにかくストレス。
GNOME Shell Extensionsに「Disable Screen Shield」というツールがあると知る。
その邪魔な画面はScreen Shieldというらしい。これを無効にしてくれる。あぁ、嬉しい。そもそもScreen Shield自体がオプトインにすべき機能だろうに、
更にはオプトアウトすら用意していない。「GNOME Screen Shield」でググると世界中で迷惑がられてます。
『アウトライナー』の基本コンセプトは、デジタル納品・デジタル配信などのデジタル形式で利用するPDFの制作支援ツールです。現在開発中である次バージョンV3.0で追加された「リンク注釈の編集機能」について書いてみたいと思います。
読み込んだPDFに、リンク注釈が存在する場合、その外観がプレビュー上に表示されます。
この矩形をダブルクリックすると、リンク注釈の設定ダイアログを開きます。
リンク注釈の設定ダイアログでは、外観の変更が行えます。
アクションの設定ボタンをクリックすると、アクションの設定ダイアログを開きます。
この例では、編集中のPDFの2ページ上の矩形領域を、飛び先に設定します。
この例では、外部PDFの13ページ上の矩形領域を、飛び先に設定します。
しおりのプロパティに追加されたボタンをクリックすると、アクションの設定ダイアログを開きます。
リンク注釈と同じように、しおりのアクションが設定できます。
ページモード時の、サムネイルビューにあるツールバーに、リンク注釈の外部ファイル入出力用のボタンが増えています。
リンク注釈及び、アクションの情報を、CSVファイル、XMLファイル、JSONファイルに書き出したり、取り込むことができます。
リンク注釈の外部ファイルのXML形式の中をみてみます。
開発中のため、仕様は変更される可能性があります。
2020年4月リリースに向けて鋭意開発中です。2020年3月中旬にはβ版を評価用にリリースする予定です。
製品に関するご質問は
outliner@antenna.co.jp（アウトライナーサポート） まで、お気軽にお問い合わせください。
評価版のお申込 評価版のお申し込み
『アウトライナー』の基本コンセプトは、デジタル納品・デジタル配信などのデジタル形式で利用するPDFの制作支援ツールです。現在開発中である次バージョンV3.0について書いてみたいと思います。
2020年4月リリースに向けて鋭意開発中です。2020年3月中旬にはβ版を評価用にリリースする予定です。
製品に関するご質問は
outliner@antenna.co.jp（アウトライナーサポート） まで、お気軽にお問い合わせください。
評価版のお申込 評価版のお申し込み
2020年2月7日、先週の金曜日に開催されたXMLパブリッシング交流会『ウェブ出版と日本語組版の未来』に参加してきました。アンテナハウスもブースを出展していた、page2020のイベントの1つという位置付けでした。
会場は池袋サンシャインシティの文化会館7F会議室。最近の技術書典の会場として2F、3Fには来たことがあったので、まあ結構ギリギリの到着でも大丈夫かと高を括っていたのですが、素直にエスカレータを登っていたらスポーツジムに着いてしまい、慌ててエレベータを探しました。
そんなこんなで本当にギリギリの時間に会場に到着すると、席は前方から後方まで割と満遍無く埋まっていました。こくちーずでの申込数上限は80人で、終了後に確認したら登録者数は57人となっていましたね。
以下、スライドや発表に解釈を加えて記述している箇所がありますが、発表者の方の意図に沿えているか分からない箇所もございます。ご了承、ご指摘ください。
Keynote for iCloud上の資料となるので、環境によってはご覧になれないかもしれません。FireFoxやSafariなら見られる筈です。
JLReq Task Force Chairmanの木田氏による、「W3C 日本語組版の処理要件」とその周辺の話となります。
原型としてはJIS X 4051:2004の「日本語文書の組版方法」となり、これを国際的な文書にまとめ直したもの、というのがJLReqの概要となります。
しかし、JLReqはJIS X 4051の単純な移植に留まらない、ということを発表を聴いて改めて意識させられました。
まず、非日本語話者にも要件を伝えるということから、JIS X 4051よりも詳細にその背景や用語の解説や図示が行われているということ。「ルビとはなにか」という説明が、ルビ文化が無い人のために必要になるといった例が挙げられました。
また、世界に向けて日本語組版における要件を発信したJLReqは、様々な言語における要件をまとめていく活動の先駆けとなりました。総称すると「xLReq」とでも言うべきこの活動は、世界が協力し多言語組版を実現していく上での重要なファクターとも言えそうです。
業界的な意味でも、W3Cの専門家と言語の専門家を繋ぐ架け橋としてxLReqがあるということでした。
JLReqTFとしても活動は続けられています。これは公開された活動で、GitHub上にインターフェースがあります。英語での意見投稿はハードルが高いと感じている方も、日本語で投稿した内容をJLReqのチームが拾い上げ、翻訳を行ってくれるとのことなので、積極的な参加を呼びかけておられました。
まず、JLReqの2版に向けた内容のアップデート。これは1版にドラスティックに変更が走るといった類のことではなく、
といった内容だそうです。
次に、JLReqの機能を滿たすようなCSSが定義されているか、あればその動作の検証の諸々と、そのドキュメント化までを行っているそうです。事前にキーワードとして挙げられていた「gap analysis」ですね。スライドの表にその例示があります。要件があっても実際にそれを実現できる仕組みがないとどうしようもないので、こういった調査を行ってくださっていることに頭の下がる思いです。GitHubで課題、意見の吸上げを行っているので、その整理自体も重要な仕事ということでした。
結びとして、「未来に向けて」という題で幾つかのお話をされました。
紙面とデジタルテキストとの違いということを軸に話されていたものの、多くは組版そのものが持っていた問題のうち、今まで人が都度なんとかしており、また完成したものが紙面など固定されたものであったために表に出ていなかったもの、という印象でした。
人間が監督するものと完全に自動で組版するものとの課題の例として、縦書きで左ルビの行と右ルビの行が隣り合うときの行間制御の例など（大抵は人間が位置をずらすことで対処）、画面サイズで文字の配置が変わる場合などに確かに考えねばならないものです。
また、世界で使われるということは、これまでの和文と欧文の高々2つの関係の独自の世界から、「多言語のうちの1つとしての日本語」ということを意識した要求にしていく必要がある、ということも「xLReq」、そしてインターネットとWebブラウザが登場してより顕在化した事柄ではないでしょうか。
そして、そもそも紙面上での組版の時代でも、媒体の事情に合わせて組版要件が変化していったということも、言われてみればその通りであるのに、見落としがちであった視点であったと思います。パラグラフマーク「¶」が、飾りではなく紙の値段が現在よりも高かったときに段落区切りを余白以外の手法で表していた、という例示がありました。
冊子の持っていた優位性の消失というのも興味深い話でした。ページを捲ることでのランダムアクセス（巻物はシーケンシャルですね）、これはデジタルテキストであればリンク機能で事足ります。新技術が登場するときに旧来の技術・表現を模倣するという視点での「デジタルテキストでの組版とその処理要件」は、どこに自分の立ち位置を合わせるかを考える上で重要なものだと感じました。
そして、参加者からの質問タイム。
「禁則処理や和欧文間のアキがJIS X 4051から引き継いでいるが、この要件を変更する議論はあるのか？」というもの。例えば「四分アキが適当な箇所と適当で無い箇所」といった具合ですね。「Tシャツ」という日本語としての単語の「T」と「シ」のアキが四分だと広すぎる、というような例が挙げられていました。
返答として、議論は行われているということでした。
関連して、和語の単語区切りのアイデアといったものも示されました。Webブラウザ表示では、日本語でも行末が不揃いであることもかなり受け入れられてきているので、今後そういった表現に関しての要件が必要になってくることも納得ですね。
「もっと皆さんに試してみてほしい」という言葉も印象的でした。
最後にされた「JLReqは今後『Rule』になるのか」という質問に対して「要件であり、複数あって良いものである」という姿勢が示されていました。その前にされたアキの変更議論なども含めての回答になっており、大変充実した内容でした。
W3Cの作業草案（Working Draft）から勧告（Recommendation）に至る流れの解説の後、それに則って進められている本題のCSS規格の話へ移ります。
勧告候補まで行っても、状況によっては差し戻しされ議論に戻ることもあるというのは随時チェックする程でない身としてはショックがありました。
最新の仕様を追うならDraftを見ることになりますが、何せ草案なので揺れて怖いという話。
「CSS3」という呼称がCSS2.1までのバージョニングの話とは違うということは
不勉強であまり意識したことがありませんでした。CSS2.1に入っていた仕様をレベル3とし、各モジュールに分けて進行状況をレベルで表すということです。
各Webブラウザでの仕様の実装状況のチェック方法など、初学者に嬉しい内容のスライドとなっていました。
JLReqの発表でもあった、要件と対応するCSSのモジュールに関しても、そのモジュールを勧告まで持っていくには別のレイヤでの議論がある、ということでした。「行どり」のためのモジュールは2つほどあったけれどどちらもポシャってしまった話からも、その難しさが察せられます。
より高度なルビ機能の実装に向けたWebブラウザの動向という例も挙げられていました。FireFoxのみ両側ルビに対応を始めたものの、他ブラウザは行っていないといったズレがあるということでした。
定まっていない仕様が定まると、どのような場合に嬉しいのかということで、
text-spacingが規格化されれば、ぶら下げインデントでの約物の表示挙動が統一されたりする、といった例が挙げられていました。
自動縦中横のアイデアなど、どう実装するのか難しそうな話題もあるようです。
また、ルビと圏点を同時に使った場合の挙動といった、議論が定まっていないものもあります。ところで、Antenna House Formatterではルビと圏点の同時使用に対応しており、挙動としてはルビ文字の上に、親文字に対応する圏点を表示します。ルビ文字に合わせた圏点は行えません。
発表スライドもVivlioStyle製です。
紙とWebでの出版コンテンツの違いについてから始まりました。
どちらかというとページメディアとスクロールメディアの違いについてと言えなくもない内容でしたが、「CSSの表現力によってコンテンツの表現力が変わる」という主張は恐らくVivlioStyleの開発陣の情熱の起点となるものではないかと感じました。
電子書籍の形態として普及が進むEPUB3の話題も当然深く拘わってきます。EPUB3.0の仕様に縦書き機能が入ったことでも話題になりましたね。これも、W3CにおけるCSS標準化の進みによるもの、JLReqが貢献した1例といえます。
そして提示された「EPUBはウェブ出版といえるか」という疑問に対し、村上さんとしては現状そうではない、という立場のようです。
「Web Publications」というそのものズバリなW3C Working Groupの存在と、それが現状停滞してしまっていること。この試みをそのまま形にする筈であったEPUB4.0も現状ではどうなるか分からない、とのこと。
また、メタデータの付与をJSON-LD形式で行うPublication Manifestについての言及もありました。こちらは勧告候補。
通常のWebページにSchema.orgに沿ったJSON-LDを付与することも聞くようになってきましたし、Webを志向する上ではそういった流れなのかもしれませんね。
各Webブラウザが機能を実装するにはとても時間がかかります。CSS Paged Media関連など、通常のWebページを表示するためのWebブラウザとしては後回しになりがちなCSS仕様もあります。一方で「標準化」のためには、いち早くその仕様を実装し、検証し、フィードバックを行うことも必要です。
CSSでの機能標準化をより強く進め、同じソースからCSSによって複数のレイアウトを実現し、印刷、EPUB、Web出版を1つのラインに載せたいという情熱を感じました。
「ここから本題です」と村上氏が発言し、会場に笑いが。確かにまだVivlioStyleの話が全然出ていませんでした。
商用のCSS組版ソフトウェアについても言及。弊社の「Antenna House CSS Formatter」の名前も上がりました。
VivlioStyleはオープンソースのJavaScriptプログラムで、EPUB Adaptive Layoutの機能やPaged Mediaなどの、Webブラウザが対応できていない機能をJavaScriptによって補完するものになります。大きなトピックとして、2019年からJavaScriptからTypeScriptに移行しました。
個人的にはVivlioStyle Flavored Markdownの話が聞きたかったのですが、デモもそこそこに時間終了となってしまいました。デモでは、同じHTMLソースからCSSの設定変更のみでレイアウトを大きく変更する例などを駆け足で紹介していました。
https://www.slideshare.net/ogwata_1959/cssvivliostyle-227189333
VivlioStyleの沿革から。スライド外の情報としては、もともとInDesignのレイアウトをWebで実現したかったのがEPUB Adaptive Layoutの思想だったということで、驚きました。
開発の活発さをコミットログから見ると、会社時代と法人化以後を比較してもあまり衰えていない様子が表示されました。開発に参加してくれているメンバーなどにアンケートを取ったところ、「VivlioStyleの開発に加わると最新仕様の実装ができる」というところに魅力を感じている方が多いとコアメンバーが驚いたとか。ちなみに、コアメンバーがそのあたりに無自覚的だったことに会場から驚きの声が上がっていました。
開発者会議を現在月1度ほどの頻度で行っており、濃密な場となっているそうです。
そして、これからも開発を継続していくために、現在法人としてのVivlioStyleに欠けている、開発者支援のための費用など用意していくために、VivlioStyleを利用したサービスを構想中ということで、「VivlioStyle Pub」の構想が紹介されました。
VivlioStyleを利用したオンラインエディタ「Viola」を元に、「ブラウザで原稿執筆可能」「PDF/X-1a出力可能」「（独自仕様の）Markdown原稿をサポート」を目玉にサービスを行っていくというもののようです。VivlioStyle Pubとしては技術同人誌出版などを当面のターゲットとし、印刷所との連携などまで持っていくつもりとか。
VivlioStyle開発メンバーでもあるspring-raining氏のCSS組版・パブリッシング交流会でのViolaの発表が去年の6月ごろだったことを考えると、こういったプロジェクトでの歯車が噛み合う瞬間の速度というものの凄まじさを感じずにはいられません。同じく去年のCSS組版・パブリッシング交流会で課題として挙げられていたPDFの規格問題もGhostScriptでのアウトラインフォント埋め込みを実装したメンバーがVivlioStyle開発メンバーに参加したということです。
CSSの未だ定まっていない仕様も、それを実際に実装し、フィードバックしていくシステムを調えていくこともまた重要で、どんな立場からでもその立場なりにできることがあるということを強く印象づけるXMLパブリッシング交流会となりました。
伊那谷は長野県の南にあり、天竜川に沿った南北に細長い地形で、太平洋側と日本海側を結ぶ回廊のような位置にあります。
古くから太平洋側の東海地方と山国信州を結ぶ交通の要衝だったため、戦国時代には多くの武将たちが勢力を競い城を築きました。
伊那谷には、これらの城跡が今もなお各所に残されています。
伊那谷の魅力のひとつは、こうした城跡を訪ねて歩くことができるところにもあります。
ただし、城といっても良く知られている姫路城や松本城のように立派な天守や石垣があるわけではありません。
伊那谷に残されているのは、山を削って作った堀や土を盛り上げて作った郭（くるわ。曲輪とも書く）の跡で、いわゆる「土の城」なのです。
お城愛好家の中には「土の城」にたまらない魅力を感じる方もおられますので、そうした方々にとって伊那谷は格好のお城巡りの場と言えます。
今回はそうした城巡りの第一弾として、伊那市にある「春日城址」をご紹介します。
「春日城址」はJR伊那市駅から徒歩20分くらいの距離にあり、市街地からそのまま上がっていける小高い丘の上に築かれています。
地元では桜の名所として知られていて、春には花見で大いに賑わいます。
「春日城址」公園の上り坂
城は天竜川の西側に位置し、河岸段丘の崖を利用した堅固な作りとなっています。
「春日城址」本丸
段丘の南東隅に本丸が置かれ、それを囲むようにＬ字型の二の丸、更にその外側に三の丸が位置して、それぞれの郭は深い空堀で切断されています。
「春日城址」二の丸と三の丸間の空堀
残念ながら三の丸の外側は市街地に同化されて往時を偲ぶのは難しくなっていますが、西側から三の丸、二の丸、本丸が配置された梯郭式の縄張りと言えます。
「春日城址」二の丸から三の丸に通じる橋
本丸は、北と西にある2つの橋で二の丸と結ばれています。
「春日城址」二の丸から本丸に通じる橋
本丸からは東側に天竜川と、その周辺に広がる伊那谷の風景が一望できます。
「春日城址」本丸から東側を望む
手前の山地の左奥にコヒガンザクラで有名な高遠城址があり、春日城の戦略的な位置づけも確認できるでしょう。
「春日城址」の魅力は、市街地から気軽に、戦国の城特有の深く刻まれた空堀や郭の、良好に残された遺構を体験できるところです。
また、晴れた日には南アルプスを遠くに見ることもできて、城址の静寂と雄大な風景を贅沢に楽しむひとときを満喫できます。
お城好きならずとも、是非一度は訪れてみてください。
アウトライナー製品担当です。
先週2月5日から7日の3日間にかけて、サンシャインコンベンションセンターにて開催されたpage2020では、多くのお客様にご来場をいただきました。改めまして、この場を借りて御礼を申し上げます。
今回のpageでは、プロ向けのデスクトップ製品という位置づけのアウトライナーをメインの一つとして展示・紹介しました。
※アウトライナーとは、PDFのしおりを作成・編集したりPDFの目次ページの作成をするほか、PDFファイルの分割・結合や、PDFのページ順序の編集などを対話的に行える、PDF制作者向けのツールです。
開催前は「しおり・目次の作成」を主機能としたソフトウェアに関心を持ってくださる方がいるのが不安でしたが、蓋を開けてみれば大変多くの方から関心とご意見、ご要望を頂きました。
現在、バージョンアップ時の機能追加や改修として盛り込むべく、社内で検討しております。
実装検討中のご意見、ご要望について概要ではありますがご紹介致します。
上記以外でも「こんな機能があったら」など、ご要望がありましたらぜひお寄せください。
アウトライナーは30日間、正規版と同等の機能を30日間使用いただける評価版がございますので、実際に試した上で、検討頂くことも可能です。
引き続き、弊社製品をよろしくお願い致します。