View Single Post
Old 02-14-2024, 01:26 PM   #28
jhowell
Grand Sorcerer
jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.
 
jhowell's Avatar
 
Posts: 6,528
Karma: 84500001
Join Date: Nov 2011
Location: Tampa Bay, Florida
Device: Kindles
Quote:
Originally Posted by xxyzz View Post
- How fragment ids are created? Only section rows start from "c0", others start from a random id like the first anchor id is "a1B9".
The convention used for fragment id symbols has changed over time. In the end they really only need to be unique.

Conventions used in the past that can still be seen in older Amazon books include base64 values and uuids for uniqueness with varying prefixes and suffixes.

The current convention is to use a lower case letter indicating the purpose of the symbol followed by a unique value. The letter prefixes I have seen are: a=anchor, b=ruby_content, c=section, d=auxiliary_data, e=resource, f=font, i=structure, l=storyline, n=nav_container, p=path_bundle, s=style, t=kfx_id/eid, z=copy/pasted content. The suffix value increments as new symbols are created and is expressed in base-32 (0-9,A-Z excluding ILOQ).

Quote:
Originally Posted by xxyzz View Post
- How eidbucket_* rows are created?
They appear in yj.eidhash_eid_section_map fragments, present in KPF but not KFX format. The data contained is redundant with the section_position_id_map. I have not looked into why they exist or how they are created.

Quote:
Originally Posted by xxyzz View Post
- The section rows always have an non-exists kfx_id field, for example here is the text ion data of the "c0" row in the fragments table:
Code:
$ion_1_0
section::{
  section_name: kfx_id::"c0",
  page_templates: [
    structure::{
      kfx_id: kfx_id::"i3",
      story_name: kfx_id::"l4",
      fixed_width: 1400,
      fixed_height: 2100,
      layout: scale_fit,
      float: center,
      type: container
    }
  ]
}
the "i3" fragment id doesn't exist
A kfx_id is a label for a data structure, which can be an entire fragment or just a part of one. In your example "l4" is a reference to a storyline fragment while "c0" and "i3" are labels identifying that section and structure embedded within it.

The symbol "kfx_id" is used for two different purposes. "kfx_id::" is an annotation that identifies what follows as a label. "kfx_id:" is the key that identifies the label that applies to a "structure" data structure.

Quote:
Originally Posted by xxyzz View Post
- The meaning of the numbers in section_position_id_map, for example, the "c117-spm" row:
Code:
$ion_1_0
section_position_id_map::{
  section_name: kfx_id::"c117",
  contains: [
    [
      1,
      kfx_id::"i11A"
    ],
    [
      2,
      kfx_id::"i11E"
    ],
    [
      3,
      kfx_id::"i11C"
    ],
I'm not sure what's 1, 2, 3.
Those are offsets used to calculate "position" numbers. Add them to the starting position number of that section to produce the actual position number that corresponds to the book content referenced by the associated kfx_id.

There are variations in how the section_position_id_map can be organized. See process_spim() within yj_position_location.py.
jhowell is offline   Reply With Quote