kindle版と印刷版のリンク

2015/5/22 [17:09:39] (金) 天気

ほんと今さらなんだけど、kindle版と印刷版のリンクを依頼した。


ウチの場合、基本的に電子書籍オリジナルはなくて、まず最初に同人誌、紙印刷本がある。印刷本で、手元在庫がほとんどなく、品切れが近い本を電子書籍として制作して販売している。以前から同人誌版とkindle版をリンクしているかたがいるのも知っていたけど、印刷本が在庫切れを起こすケースを考えてちょっと躊躇していた。


…てなこと思ってたんだけど、ここはWEBだ。在庫が切れていても本の詳細ページは存在する。


であれば、検索でたまたまそっちのページがヒットして見にきてくれたユーザーを、品切れを起こさないkindle版へ誘導するのが定石だろう。


image
image
image

KDPヘルプの問い合わせから依頼して5時間ほどで反映されていて、吃驚の速さだった。

「お問い合わせ」→「商品詳細ページ」→「印刷版とkindle版のリンク」

(印刷版のISBN-10と書かれてるのはAmazonのASINのこと)



ちなみに。

コミケやコミティア、文学フリマなどの同人イベントで出した本、同人誌をAmazonで売るには、わたしの観測範囲では「密林社」さん経由が多い。


ウチも密林社さんに委託してAmazonのe託で同人誌を販売している。


e託はAmazonに登録すれば個人で物品の販売ができる、とはいえ、これが面倒くさい上に割に合わない。


密林社さんのサイトにも書かれているように、Amazonのe託は

・初期費用として、年会費が必要(9000円ほど)

・本一冊につき、JANコードが必要(3年1万円+税)、バーコード貼付。

・Amazonから指示された数をそのつど納品する(1冊単位で指示がくる上、送料負担がある)

・Amazonの取り分は40%(出品者に60%)


だいたい、1冊単位で注文がきて、いちいち梱包(それも箱にいれて丁寧にするように、という話だし)して送料負担して納品してたんじゃとてもやってけん。

密林社さんの取り分は10%(Amazonの取り分を差っ引いて出品者に50%)。それでこの面倒な作業代行をお願いできる。対応も丁寧でウチは信頼しておまかせしている。

(※JANコードは一冊単位ではないけど、手間はかかる)



Amazonのe託がらみでは、こちらのサイトがとても参考になる。

【「稀人舎」の軌跡】ことの起こり

http://kijinsha.blog40.fc2.com/blog-entry-3.html

カテゴリ:「稀人舎」の軌跡

http://kijinsha.blog40.fc2.com/blog-category-1.html


同人誌とは少し文脈が違って、ISBNを取得「ひとり出版社」を立ち上げよう、というブログ。

249万円で自費出版を持ちかけられたり、地方小出版流通センターに電凸して応対にキレたり、lSBN取得したり「ひとり出版社」を立ち上げるネタ・情報が満載。これは貴重な体験談&情報なので、紙で出版をしたいと思われたら絶賛オススメ!



【参考リンク】

密林社

http://www.mitsurin.com/


Amazonのe託サービス

http://advantage.amazon.co.jp/gp/vendor/public/join

Amazon e託サービスに関する説明及び規則

https://www.amazon.co.jp/gp/seller-account/mm-product-page.html?topic=201463320

[更新]2026-02-01 09:26:12

論理目次と視覚目次を別にする

2013/5/22 [15:36:21] (水) 天気

先日「目次にルビをつけてください」というリクエストにのけ反った。


『電子書籍の目次が難しい』http://t2aki.doncha.net/?id=1366594374

この時、教えてもらって、論理目次と視覚目次を別に作って対応。忘れないうちにメモしておこうと、すっかり忘れてたので改めてメモ。


EPUB3の目次は2種類。

・デバイスやアプリで使うための「論理目次」

・画面に表示するための「視覚目次」


たぶん、ひとつの目次ファイルを両方に使うことが多いと思う(って、『EPUB3::かんたん電子書籍作成』 が、ひとつの目次ファイルを論理目次と視覚目次に使っている)


でも、論理目次は使えるタグが限られていて、ルビタグなどはエラーになる。


そこで、論理目次とは別ファイルで視覚目次用のファイルを作る。こっちは本文のページと同じくxhtmlファイルとして使われるので、ルビタグも使える。


・パッケージファイル content.opf


manifest部分
<item id="nav" href="text/nav.xhtml" media-type="application/xhtml+xml" properties="nav" />
<item id="text.display.xhtml" href="text/display.xhtml" media-type="application/xhtml+xml" />

spine部分
<!--    <itemref idref="nav" linear="no" /> -->
<itemref idref="text.display.xhtml" linear="yes" />

manifestで視覚目次も指定しておいて、spineでは視覚目次を入れて、論理目次を外してしまう。


・ナビゲーション文書 nav.xhtml


toc 部分
<nav epub:type="toc" id="nav">
  <h1>目次</h1>
      <ol>
       <li style="diplay:none;" hidden="hidden"><a href="display.xhtml">目次</a></li>
       ...
      </ol>
</nav>

landmarks 部分
<nav epub:type="landmarks" id="landmarks" hidden="hidden" style="display:none;">
  <h2>Guide</h2>
    <ol style="list-style-type:none;">
      <li><a epub:type="cover" href="cover.xhtml">表紙</a></li>
      <li><a epub:type="toc" href="display.xhtml">目次</a></li>
      <li><a epub:type="bodymatter" href="title.xhtml">本文</a></li>
    </ol>
</nav>

ナビゲーション文書の目次部分(toc)には、視覚目次を入れておく(目次に「目次」という項目があるのはイヤなので display:none として、ここでは表示させないようにした)

landmarks 部分に視覚目次を指定しておく。


・視覚目次 display.xhtml

視覚目次はナビゲーション文書のtoc部分(olタグ)だけのファイルで、ルビなどのタグが使える。


クライアントからのリクエストはこれで解決だった。


こうすることで、レイアウト・デザインが自由にできる目次が可能だけど、目次をふたつ持つことで間違いの元がひとつ増える。本当はひとつで済ませたいところだったなあ。


ちょっと勉強すれば誰でも作れる

2012/5/22 [22:26:11] (火) 天気

WEBサービスの話だ。

phpを久しぶりに触ってみて思ったんだけど、perlにしろphpにしろ、以前少しだけ触ったrubyにしろpythonにしろ、WEBサービスに使われているような言語は、習得・修得のハードルが低い。誰でもちょっと勉強すればWEBサービスは作れる。フレームワークがわからなくても、functionをベタに並べて書いていくだけで、カタチになる。実際、プログラムなんて勉強もしたことのないわたしでもいくつかWEBサービスを作って公開している(ソースコードはぐちゃぐちゃだけどね)

なもんで、いまどき、WEB用のライトウェイトランゲージが使えると言っても、なんのアドバンテージにもならない。開発言語はどうでもいい。


それよりも。

何をしたいのか、何を作りたいのか、どんなユーザーを対象にするのか、そのためにどんな知識が必要で、作りたいものに密着した利便性を考えてどんな機能を作るのか、WEBサイトの使い勝手はどうするのか。

で、さらに、使ってもらうために、集客・そこにひとを集めるのはどうするの。

誰でもWEBサービスを作って公開できるとなると、最先端の技術を投入してスゲーの作ったらから使って、なんてのは的外れなだけ。使う側は技術になんて興味はない。はてなブログの失敗はそこだろう。

自分の興味対象に対して、強い動機があって初めて、使ってみたいものができる。痒いところに手が届く、を、そこきたか、と思わせるものができる。

以前から言ってるように、WEBサービスなんてのはしょせんただのガワ、ウツワ。何を入れるのか、どうすれば思ったように入ってくれるのか、そこを考えられる資質こそ必要。


WEBサービスとして、それで金になるかどうか・社会貢献できるかどうかも含めて、面白いかどうかの判定できるようにしたいもんです。


いや、一言でいうと、なんか面白いことしたいよー、というだけの話。


Twitter・Facebook・YouTube・Ustream── ”ソーシャル”なサイト構築のためのWeb API コーディング

『Twitter・Facebook・YouTube・Ustream── ”ソーシャル”なサイト構築のためのWeb API コーディング』

MdN編集部

[更新]2026-02-02 15:14:47

「趣味は読書2」など読書記録WEBサービス

2011/5/22 [19:03:06] (日) 天気

WEBのまとめページとか2ちゃんにリンクされてる読書記録、蔵書管理のWEBサービスたちを一覧してみた。


趣味は読書2

http://doncha.net/


ブクログ

http://booklog.jp/

たなぞう

http://review.webdoku.jp/

MediaMarker(メディアマーカー)

http://mediamarker.net/

読んだ4!(twitter)

http://yonda4.com/

Stack Stock Books(スタック・ストック・ブックス)

http://stack.nayutaya.jp/

本棚.org

http://www.hondana.org/

Bookboard.jp

http://bookboard.jp/

今読ミ

http://imayomi.jp/

CROSSREVIEW

http://crossreview.jp/

InBookjp

http://inbook.jp/

読書メーター

http://book.akahoshitakuya.com/

BookScope

http://bookscope.net/

Socialtunes(ソーシャルチューンズ)

http://socialtunes.net/

ほんつな

http://www.hontsuna.com/

Bossa Books

http://www.bossabooks.jp/cafe/

ソーシャルライブラリー

http://www.sociallibrary.jp/

Web本棚

http://webbookshelf.jp/

みんなの本棚

http://www.mindana.jp/

読書の定義

http://dokusho.noteigi.com/

マイルーツ

http://www.myroots.me/

BookScope

http://bookscope.net/

腰帯.com

http://koshiobi.com/


ほんといろいろある。ウチも含めて、どれもこれも一長一短。これで決まり、というのがない。しいてあげると、残念ながらウチ「趣味は読書2」ではなくて、評判を見る限り「メディアマーカー」が、良さそう。


いろいろ試してみませんか?


本を読むひとの数を増やしたい、小説を面白がってくれるひとを増やしたい、たくさん面白い小説を読みたい、というのはどのサービス提供者にも共通することだと思うんで、みんなで盛り上げられればいいなあ、と思うですよ。


ちなみに、リアル本棚もやっぱりひとそれぞれ楽しいものが作れる。うーん。こっちもいいなあ。

清く正しい本棚の作り方

『清く正しい本棚の作り方』

(TT)戸田プロダクション

[更新]2012-06-18 10:06:00

へろへろ

2005/5/22 [21:06:07] (日) 天気

昨日は自治会の毒気に当てられたせいか、部屋でウィスキーを飲み過ぎ。眼痛に頭痛で夕方まで瀕死状態だった。うううむ、自治会費の集金やら防災委員や、どっぷり濃い人間関係に巻き込まれそうだぞ。

んで、ぼーっと起きて息も絶え絶えながら、とりあえず真メガテン2。


ネタもなんもなし、ですよ

<<2026/05>>
     12
3456789
10111213141516
17181920212223
24252627282930
31

【最近の10件】

日常読書映画アニメゲーム健康料理グルメカメラ写真ネタ仕事パソコンインターネットperlEPUB3電子書籍ActivityPub
検索: