openpecha / toolkit

🛠 Tools to create, edit and export texts and annotations

OpenPecha Toolkit

Description • Owner • Install • Docs

---

Description

OpenPecha Toolkit allows state of the art solution for distributed standoff annotations on moving texts, in which Base layer can be edited without affecting annotations. This is made possible by our OpenPecha Native Format called opf (OpenPecha Format) and our collection of importers which can parse existing text into opf and exporters which can export opf text into any format (.epub, .docx, .pdf, etc)

Owner

• @10zinten

💾 Install

Stable version:

pip install openpecha

Daily development version:

pip install git+https://github.com/OpenPecha/Openpecha-Toolkit

Docs

• Documentation: docs
• If you have any problems with openpecha-toolkit, please open issues

Developer Installation.

git clone https://github.com/OpenPecha-dev/openpecha-toolkit.git
cd openpecha-toolkit
pip install -r requirements-dev.txt
pip install -e .
pre-commit install

Testing

PYTHONPATH=.:$PYTHONPATH pytest tests

toolkit's Issues

Build CLI for OpenPoti

Adding CLI for OpenPoti Toolkit using CLICK or QuickUI

Annotation Update

• Implement Tofu ids:
  • Create Tufu-ids manager class
  • Recovery method for lost tofu-id
• Use Tofu-id to update the annotation

"update" description might be confusing for users

it reads: "Command to update the annotations, must be run making edits to base text."

when run, it reads: "Updating annotations to [Work ID]".

from a user perspective, i think this might be confusing. the user is making changes to the base text. and updating the base text. right? if i'm not mistaken, it is then the software that—based on changes to the base text—makes updates to the index in the annotation layers.

if i am a normal user, i think i don't actually care about this. i wouldn't know how it works. in my mind, i am updating the base layer (not the annotations). so an improvement could be:

"Command to update the base text with your edits."
"Updating [Work ID] base text".

JSON over YAML for index and layers

Comparison

YAML is human-friendly therefore, great for manual editing but it's slow.
JSON is not human-friendly but much faster than YAML for both loading and dumping.

Our use case

• We are facing a very slow loading of index.yml for katen pechas at the moment.
• There is no limit to the size of index.yml and layers.yml files. This will lead to very slow loading and dumping for large layers files.
• Index and layers are not intended for manual editing therefore, I propose to use JSON over YAML for index and layers.

TODO:

• convert all the index.yml and .yml to .json with cli
• Load and dump json in formatters
• Load json in serializer.

@eroux @ngawangtrinley @kaldan007

Major Revision from /buda

• rename poti into pecha in function names, etc. in Lou's code
• the modules in buda/ should be in the main directory
• rename github_utils.py into git_utils.py and integrate some of the function from op_bare.py
• integrate the functions from serialize.py into op.py
• glossary of variable name conventions:
  • lname = local name = P0001
  • qname = qualified name = op:P0001 where op: is a namespace
  • fname = file name
• merge rdf_setup.py into rdf.py in serializers/

wrong base / volume correspondence

in https://github.com/OpenPecha/P000525 layer v001 is associated with bdr:I1KG2126 (volume 1), while it's in fact the OCR of bdr:I1KG13691 (volume 11). Given that we have the Google OCR of each image it's probably easy to recover which volume should be associated with which base layer

test

`get_result` is unnecessarily serializing all the volumes.

Is your feature request related to a problem? Please describe.
https://github.com/OpenPecha/openpecha-toolkit/blob/f30e51d5f2419007985b3e02701f2b712b38f28d/openpecha/serializers/serialize.py#L341

get_result is unnecessarily serializing all the volumes. Need a way to specify a particular volume to be serialized.

Describe the solution you'd like
accept vol_id or yield current vol result

What would be the output for dmp_find()

https://github.com/OpenPoti/openpoti-toolkit/blob/edcfdf76c738a701962e8fd0a4b21118909be1ca/openpoti/blupdate.py#L134

What would be the output for context = (ghi, jkl) and dstcoordestimate = 8, computed with srcblcoord = 7 based on the same example in the code

add version in CLI

It should be possible to see the version in the CLI, it could be either:

• adding the version number somewhere in the --help message
• adding a --version option

HFML Formatter Fails test cases

Test cases where HFML Formatter fails
Test case 1

[68a.6]མཐོང་བས་ནི་ཤིན་(དུ་,ཏུ་)མཐོང་། །ཆོས་ཉིད་མཐོང་བ་མ་ཡིན་ནོ། །ཁོང་སྟོང་ཁྱོད་ཀྱི་སྐུ་ལ་མེད། །ཤ་དང་རུས་པ་ཁྲག་མེད་ཀྱང་#། །ནམ་མཁའི་དབང་པོའི་གཞུ་བཞིན་དུ། །ཁྱོད་ཀྱི་སྐུ་ནི་སྟོན་པར་མཛད། །སྐུ་ལ་བསྙུན་མེད་མི་གཙང་#མེད། །བཀྲེས་དང་སྐོམ་པ་འབྱུང་མེད་ཀྱང་། །ཁྱོད་ནི་

Error message

File "/home/tenzin/ML/project/Esukhia/openpecha-toolkit/openpecha/formatters/hfml.py", line 121, in search_before
    length_before = length_before + (len(s[0])-len(error_part))
NameError: name 's' is not defined

New OpenPoti Formatter based on annotation char coordinate

• Test and Merge the OPFormatter (which is new OpenPoti layer formatter based on annotation char coordinate) to master.

• Generate new layer format for all OpenPoti works.

https://github.com/OpenPoti/openpoti-toolkit/blob/6f23f4f7dd947df4b016e10b65f436dfe6e048e2/openpoti/formatter.py#L6

Required line-return in Tibetan Text

OCR shouldn't overwrite the existing Google OCR json files on s3

During the process of re-OCRing W22084, the previous OCR json files on s3 were overwritten, this shouldn't happen. If the directory s3://ocr.bdrc.io/Works/60/W22084/vision/batch001/ exists, it should have create batch002

HFML Serializer

• add TEI reference for HFML tag
• Implement SerializerHFML
• Implement mechanism to Add/Edit annotation
• Create test suits

Make release names unique

any export should have a name unique so users can differentiate a) texts with the same name, and b) multiple exports of the same view on their machines.

སྨོན་ལམ།.epub can be very ambiguous.

We need something like:
<truncated title transliteration?><2 last digits of pecha><version?><incremental serial number?>

<truncated title transliteration?> github doesn't seem to like unicode in file names, so we could use wylie without (') or even better a phonetic transliteration.

Padmakara EN int. looks like the best one for our use case

using data/catalog.csv instead of README.md

in https://github.com/OpenPecha/openpecha-toolkit/blob/master/openpecha/buda/openpecha_manager.py#L41 (as the README is not up to date)

Toolkit Desktop app

• Flask with Pywebview
• CLI to GIU
  • examples
  • Video Converter example

[RDF] don't create RDF resources for empty volumes

here's an example of such an empty volume: https://github.com/OpenPecha/P004631/blob/master/P004631.opf/base/v006.txt . I'm not sure it's a really good thing to create these when the OCR is run, but once it's done, the RDF export should handle it better

MVP Todo

• Local id support for HFML serializer

• Test whole HFML workflow:

  • Add new annotation
  • Edit anntation
  • Delete annotation

• CLI command for:

  • HFML formatter
  • HFML serializer
  • Ebook serializer

• Github Action

  • HFML format and serialize
  • opf Export

• Entry point:
  1. HFML -> opf -> HFML with local-id

• Release and download

Upgrade pyyaml version in requirements

I can't install openpecha on my machine because of pyyaml

https://github.com/OpenPecha/openpecha-toolkit/blob/master/requirements.txt#L41
Installation of PyYaml 5.1.2 fails on Windows...

...but it's just fine with the latest version

forcing the -bo option in Google OCR?

Here are some remarks from someone who uses OpenPecha on BUDA and is also uses Google OCR directly:

Oh, as I start to use the e-text facility of
https://library.bdrc.io/
I notice that occasionally google ocr has OCR'd Tibetan as Devanāgari!
I wonder if -bo option was used during OCR and google overroad it, or it was left in multilingual mode.
I have not seen this behavior in my own use of the -bo option.

Do we force the language to Tibetan when we run the OCR?

OCR: bug in certain layouts

This is something that we can live with and is probably very difficult to fix in an automatic way, but when a pecha has an illustration in the middle (like in this image), the OCR considers the left part of the image to be one paragraph, and the right part to be another one, while in fact this is one long paragraph where each line is split in two. Here's the result for this specific page:

/oM swa sti/_skyabs 'gro yan lag drug pa 'di la don bzhi las/_dang po
yan lag drug pa/_gnyis pa 'gyur gyi phyag dkon mchog gsum la phyag 'tshal
dang |_gzhung don dngos bshad pa'o/_/dang po ni/_skyabs 'gro yan lag drug pa bshad//
yul dus dgos pa dang /_/phan yon bslab bya blang ba rnams/_/rtsa ba sdom
dang dkon mchog gsum gyi yon tan dran pas skyabs su 'gro/_/gnas gsum bstan
mtshan gyi don/_rgya gar skad du/_Sha TAng+ga sha ra NaM/_bod skad du/_skyabs 'gro
lo/_/gsum pa gzhung gi don la gnyis/_brtsam par dam bca' ba bsdus don dang bcas pa
gnyis pa la gnyis/_mdor bstan pa dang /_rgyas par bshad pa'o/_/dang po ni/_cis 'gro
du bshad pa yin/_/gnyis pa rgyas par bshad pa la rim par/_'khor ba la/_'jigs
pa'i yul de la/_/'di nas byang chub thob bar ro/_/mu stegs spyod las log
rtsa ba'i chos sde 

Incorrect text spans

List of incorrect text span:

• D4026

txt and epub download buttons

something like this:

fallback `reference` in Page annotation

https://github.com/OpenPecha-dev/openpecha-toolkit/blob/0265d00bdc4a13d326e798541b5d52a03b7e407f/openpecha/formatters/google_orc.py#L42

return fn object instead of fn.stem

https://github.com/OpenPecha-dev/openpecha-toolkit/blob/0265d00bdc4a13d326e798541b5d52a03b7e407f/openpecha/formatters/google_orc.py#L162

check if the page has an extension name, if not then use fn name as fallback

CCTV fails if there are changes in the layer text.

CCTV fails at following cases:

srcbl = abefghijkl
dstbl = abcdefgkl
CCTV = [(0, 2, 0), (2, 5, 2), (8, 10, -1)]

Note: - is the annotation

Cases:

1. Changes at beginning of layer text

   	source	destination
   layer_text	ab-efg-hijkl	abc-defg-kl
   anno	(2,4)	(3,6)

   get_updated_coord():
   - input = 2, cctv = 2, output = 2+2 = 4
   - input = 4, cctv = 2, output = 4+2 = 6

   Expected output should be (3, 6)

2. Changes at end of layer text

   	source	destination
   layer_text	ab-efghijk-l	abcd-efg-kl
   anno	(2,8)	(4,6)

   get_updated_coord():
   - input = 2, cctv = 2, output = 2+2 = 4
   - input = 8, cctv = -1, output = 8-1 = 6

   Expected output should be (3, 6)

TEI export

84000 needs an export in TEI for import. There used to be an export on the previous derge-kangyur repos:

https://github.com/Esukhia/derge-kangyur/blob/master/scripts/toTei.py

it should be adjusted to the opf format and integrated here

(cc @Celso-Scott @domlatham )

error in a pecha yaml format, crashing the toolkit

Unfortunately I can't really know which pecha does this, but I can't import the openpecha in BUDA anymore because of this error when I run the import (after pulling the latest version of the pechas):

Converting into rdf:  81%|########################################################################################################################1                            | 3455/4283 [37:29<01:30,  9.16it/s]
Traceback (most recent call last):
  File "/home/admin/.local/bin/openpecha", line 11, in <module>
    load_entry_point('openpecha', 'console_scripts', 'openpecha')()
  File "/home/admin/.local/lib/python3.7/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/home/admin/.local/lib/python3.7/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/home/admin/.local/lib/python3.7/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/admin/.local/lib/python3.7/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/admin/.local/lib/python3.7/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/admin/openpecha-sync/openpecha-toolkit/openpecha/cli.py", line 418, in cache_to_store
    opm.sync_cache_to_store(store_uri, ldspdi_uri, force, opids)
  File "/home/admin/openpecha-sync/openpecha-toolkit/openpecha/buda/openpecha_manager.py", line 209, in sync_cache_to_store
    if not op.is_ocr():
  File "/home/admin/openpecha-sync/openpecha-toolkit/openpecha/buda/op.py", line 44, in is_ocr
    meta = self.get_meta()
  File "/home/admin/openpecha-sync/openpecha-toolkit/openpecha/buda/op.py", line 40, in get_meta
    self.meta = self.read_meta()
  File "/home/admin/openpecha-sync/openpecha-toolkit/openpecha/buda/op.py", line 35, in read_meta
    return self.read_file_content_yml("meta.yml")
  File "/home/admin/openpecha-sync/openpecha-toolkit/openpecha/buda/op_bare.py", line 30, in read_file_content_yml
    return yaml.safe_load(ymlstr)
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/__init__.py", line 162, in safe_load
    return load(stream, SafeLoader)
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/__init__.py", line 114, in load
    return loader.get_single_data()
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/constructor.py", line 41, in get_single_data
    node = self.get_single_node()
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/composer.py", line 36, in get_single_node
    document = self.compose_document()
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/composer.py", line 55, in compose_document
    node = self.compose_node(None, None)
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/composer.py", line 84, in compose_node
    node = self.compose_mapping_node(anchor)
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/composer.py", line 133, in compose_mapping_node
    item_value = self.compose_node(node, item_key)
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/composer.py", line 84, in compose_node
    node = self.compose_mapping_node(anchor)
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/composer.py", line 133, in compose_mapping_node
    item_value = self.compose_node(node, item_key)
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/composer.py", line 64, in compose_node
    if self.check_event(AliasEvent):
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/parser.py", line 98, in check_event
    self.current_event = self.state()
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/parser.py", line 449, in parse_block_mapping_value
    if not self.check_token(KeyToken, ValueToken, BlockEndToken):
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/scanner.py", line 116, in check_token
    self.fetch_more_tokens()
  File "/home/admin/.local/lib/python3.7/site-packages/yaml/scanner.py", line 260, in fetch_more_tokens
    self.get_mark())
yaml.scanner.ScannerError: while scanning for the next token
found character '\t' that cannot start any token
  in "<unicode string>", line 6, column 16:
      publication:      སྡེ་དགེ་པར་ཁང་།
                   ^

Pillow preprocessing guide line

Test the difference between OCR on web images and OCR on Archive images.

Tests should cover:

• archive vs web images
• modern printed text of 3 or 4 different quality
• manuscript samples
• blockprint samples
• various scripts
• color vs B&W

Unicode Error in Windows while using "download"

error when using command "openpoti download"

PS D:\GitHub\Esukhia\openpoti-toolkit> openpoti download -i W1OP000001 Traceback (most recent call last): File "C:\Users\user\AppData\Local\Programs\Python\Python36\Scripts\openpoti-script.py", line 11, in <module> load_entry_point('openpoti', 'console_scripts', 'openpoti')() File "c:\users\user\appdata\local\programs\python\python36\lib\site-packages\click\core.py", line 764, in __call__ return self.main(*args, **kwargs) File "c:\users\user\appdata\local\programs\python\python36\lib\site-packages\click\core.py", line 717, in main rv = self.invoke(ctx) File "c:\users\user\appdata\local\programs\python\python36\lib\site-packages\click\core.py", line 1137, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "c:\users\user\appdata\local\programs\python\python36\lib\site-packages\click\core.py", line 956, in invoke return ctx.invoke(self.callback, **ctx.params) File "c:\users\user\appdata\local\programs\python\python36\lib\site-packages\click\core.py", line 555, in invoke return callback(*args, **kwargs) File "d:\github\esukhia\openpoti-toolkit\openpoti\cli.py", line 147, in download potis = get_poti(kwargs['id'], kwargs['batch'], kwargs['filter']) File "d:\github\esukhia\openpoti-toolkit\openpoti\cli.py", line 71, in get_poti catalog_path.write_text(r.content.decode('utf-8')) File "c:\users\user\appdata\local\programs\python\python36\lib\pathlib.py", line 1194, in write_text return f.write(data) File "c:\users\user\appdata\local\programs\python\python36\lib\encodings\cp1252.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode characters in position 45-47: character maps to <undefined>

Make `get_context()` smarter with dmp `patch_addContext(self, patch, text):`

Improve get_context() to return better context for srcblcoord with patch_addContext(self, patch, text): from dmp

https://github.com/jreese/dmp/blob/master/dmp/diff_match_patch.py#L1366

[Refactor Required] Tsadra parser

Current Tsadra parser

• Bad readibility
• challenging to debug
• hard to introduce new annotation
• good to have tsadra template in a template directory

Google OCR Parser

• OCR json parser
  • Page and Line span
  • Character coordinate --> image layer
• Complete one unit of OCR

Tsadra workflow

• TsadraFormatter
  • Build layer
  • Format layer
• HFML serializer support for Tsadra annotations.
• HFMLTextFormatter support for Tsadra annotations.
• Test with HFML Formatter

OCR --> S3 --> OPF

OCR --> S3 : json.gzip + images
OCR --> opf: base text + page layer
OCR --> opf release: boundingPoly zipped

function to update the base layer

There should be a function to update the patches based on an update of the base layer, here it is decomposed:

• BaseLayerUpdate is an object that can be initialized with either
  • a commit revision id
  • previous + current versions of the base layer
• at initialization it computes a character coordinates translation vector (CCTV) for the difference between the versions, as a list of tuples (see example below)
• it has a function update_patch(patch) that returns an updated version of a patch, by:
  • modifying the patch character coordinate with the CCTV
  • ask dmp to apply the patch with the updated character coordinate
  • ask dmp the new diff, which may update both character coordinate and context
• get_patch_bsl_gitrev() is a function that gets the git revision of the base layer against which the patches of the repository have been built, which is recorded somewhere in the metadata (I don't know the format)
• update_patches.py is a script that:
  • calls get_patch_bsl_gitrev()
  • compares it with latest commit rev of the base layer in
  • if different, creates a BaseLayerUpdate, reads all the patches in the repo and updates them using update_patch(patch)

CCTV example :

• version 1 is : abdf
• version 2 is : bcdef
• vector is [(0,-1),(2,0),(3,1)], meaning
  • for characters above 0, add -1 to character coordinate
  • for characters above 2, add 0 to character coordinate
  • for characters above 3, add 1 to character coordinate
  • (each instruction supersedes the previous one)

Refactoring Ebook serailizer

• Change serialize_epub.py module name to epub.py
• Change SerializeTsadra to EpubSerializer
• Test fonts on devices such as:
  • IOS
  • Android

Which bdrc work api to use

we found two different work API and we are not sure which one we should be using to get the latest data.

https://www.tbrc.org/xmldoc?rid=W22084
http://purl.bdrc.io/graph/W22084.ttl

fix required at
https://github.com/OpenPecha-dev/openpecha-toolkit/blob/0265d00bdc4a13d326e798541b5d52a03b7e407f/openpecha/formatters/google_orc.py#L187-L226

annotation transfer in CLI

Given A and B, two different versions of the same text, users should be able to transfer annotations from A to B.

'openpecha transfer '
'openpecha transfer A.txt B.txt a'

HFML Formatter

• Kangyur parser
  • Spelling and Yigchung: https://github.com/Esukhia/derge-kangyur#format
• Extract page information as payload.
• Remove extracting line number.
• Cross volume annotations.
  • Text id
  • Other annotation
• Implement layer formatting

OpenPecha Docs

• setup mkdocs
• add introduction of OpenPecha
• what is base and layers
• layer format
• types of annotaions and format

GH-Page for pecha readme+releases

automate filling up the readme of pechas, including a link to releases:

• release 0 :
  • release sources: (pdf/docx/epub/boundingPoly)
  • update https://github.com/OpenPecha/openpecha-catalog
  • create repo description:

<ID when available W###> <Title in Tibetan> <Author> <Topic>

- [ ] create readme: 

# Title
- author

## Source: 
From : <source url>
ID : 

## Downloads:
- epub, docx # for later
- base text

## Layers: # list of layers
- a : definitions # tag : name
- b : 
- dsds

## Log:
- date: activity

• release 1- : clean base, base+anno in hfml # to be determined
• something like this:

hfml build_layer revision

• Parse Tofu-id
• Create annotation dict inbuild_layer method itself. (Reduces the complexity of converting list of tuple annotation to dict annotation)

Epub serializer test missing

Adding and correcting annotations

Adding and correcting annotations

Motivation:

There are many unannotated text and incorrect annotation from ebooks that we parsed.

https://github.com/OpenPoti/openpoti-toolkit/blob/master/tests/data/serialize_test/W1OP000198/all_expected.txt

Basic Plan

• Letting user to add and correct annotations
• Need an easy way to get annotation feedback from user, since user might be using any of the export format that OpenPoti supports.

support for adding pecha repo `description` during creation

Change annotaion list in index to key-value pair (dictionary) annotations.

Currently annotations in index are list and also parts are list. For eg:

https://github.com/OpenPecha/P000001/blob/561c31601d9970549ff6dc41b61ae05b5d4357c8/P000001.opf/index.yml#L5-L21

annotations:
  - id: 51f58796058b461ab32f3c972ee5417c
    work: T1
    parts:
      - id: 3cbe647abf404688a79c24d14742826c
        work: T1-1
        span:
          - vol: base/v001
            span:
              start: 28
              end: 396711
      - id: 4993722a64084f1da94b10ce89482014
        work: T1-2
        span:
          - vol: base/v001
            span:
              start: 396712
              end: 67199

Since we have already adopted annotations as key-value pair (dictionary) for layers. Lets follow the same for index annotations. Like this

annotations:
  51f58796058b461ab32f3c972ee5417c:
    work: T1
    parts:
      3cbe647abf404688a79c24d14742826c:
        work: T1-1
        span:
          - vol: base/v001
            span:
              start: 28
              end: 396711
      4993722a64084f1da94b10ce89482014:
        work: T1-2
        span:
          - vol: base/v001
            span:
              start: 396712
              end: 67199

handle missing volumes in RDF export

see OpenPecha/ocr-queue#6 for the change in the data format

CCTV fails at following example

srcbl:

༄༅༅། །རྒྱ་གར་སྐད་དུ། ཨཥྚ་མ་ཧཱ་སྠཱ་ན་ཙཻ་ཏྱ་སྟོ་ཏྲ། བོད་སྐད་དུ། གནས་ཆེན་པོ་བརྒྱད་ཀྱི་མཆོད་རྟེན་ལ་བསྟོད་པ། འཇམ་དཔལ་གཞོན་ནུར་\nགྱུར་པ་ལ་ཕྱག་འཚལ་ལོ། །དང་པོ་བྱང་ཆུབ་མཆོག་ཏུ་ཐུགས་བསྐྱེད་ནས། །བསྐལ་པ་གྲངས་མེད་གསུམ་དུ་ཚོགས་བསགས་ཏེ། །བྱང་ཆུབ་སྙིང་པོར་སངས་རྒྱས་བདུད་ནི་བཏུལ། །བྱང་ཆུབ་ཆེན་པོའི་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །ཆོས་ཀྱི་གཞིར་གྱུར་སེར་སྐྱའི་གྲོང་ཁྱེར་དུ། །སྒྱུ་མའི་\nཡུམ་ལས་ཟས་གཙང་ཤཱཀ་རིགས་འཁྲུངས། །སྐུ་བཞེངས་སྟ་ཟུར་གཡས་ལ་ཚངས་པ་བཞེས། །བཀྲ་ཤིས་འབྱུང་བའི་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །བཱ་རཱ་ཎ་སཱི་ལ་སོགས་བསོད་སྙོམས་གཤེགས། །གཟུགས་ཅན་སྙིང་པོའི་གླང་ཆེན་སྨྱོན་པ་རྣམས། །ཕྱག་གི་སོར་མོའི་སྟོབས་ཀྱིས་\nབཏུལ་ནས་ཀྱང་། །གྲོང་ཁྱེར་འདུལ་མཛད་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །ནེ་གསིང་དག་ཏུ་བསྙེལ་སོ་མཛད་པའི་ཚེ། །ཧ་ལུ་མཉྫུས་སྦྲང་རྩི་ཕུལ་ནས་ཀྱང་། །ཁྲོན་པར་དུས་བྱས་སུམ་ཅུ་རྩ་གསུམ་སྐྱེས། །ཐུགས་རྗེ་འབྱུང་བའི་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །ཚངས་པས་འཁོར་ལོ་ཕུལ་\nནས་འཁོར་ལོ་བསྐོར། །མུ་སྟེགས་སྟོན་པ་དྲུག་ནི་སྟོབས་ཀྱིས་བཏུལ། །སྤྲུལ་པའི་གྲངས་ཀྱིས་ལྷ་མི་ཚིམ་མཛད་པའི། །ཆོ་འཕྲུལ་བསྟན་པའི་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །དགའ་བོ་ལ་སོགས་ཀླུ་ཡི་ཚོགས་རྣམས་ཀྱིས། །བསྙེན་བཀུར་འབུལ་བའི་བུ་མོས་འོ་མ་དྲངས། །བཀའ་དང་\nའཇིག་རྟེན་མ་ལུས་ཚར་གཅོད་པ། །ཉེར་ཞི་རྒྱལ་བའི་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །བྱང་ཆུབ་སེམས་དང་རང་སངས་རྒྱས་རྣམས་དང་། །ཉན་ཐོས་དགྲ་བཅོམ་ཚོགས་ཀྱིས་ཡོངས་བསྐོར་ཏེ། །སྡོམ་དང་ཚུལ་ཁྲིམས་ལ་ནི་རབ་བཀོད་པའི། །རྣམ་པར་དག་པའི་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །སེམས་\nཅན་མི་རྟག་འདུལ་བའི་དགོངས་པ་དང་། །ལྷ་ལས་བབས་ནས་མཛད་པ་ཀུན་གྱི་མཐར། །ཙུན་དས་གསོལ་བཏབ་ཟླ་གསུམ་ནས་མཐར་ཕྱིན། །མྱ་ངན་འདས་མཛད་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །གནས་ཆེན་པོ་བརྒྱད་ཀྱི་མཆོད་རྟེན་ལ་བསྟོད་པ། །སློབ་དཔོན་ཆེན་པོ་ཀླུ་སྒྲུབ་ཀྱིས་མཛད་པ་\nརྫོགས་སོ།།

dstbl:

༄༅༅། །རྒྱ་གར་སྐད་དུ། ཨཥྚ་མ་ཧཱ་སྠཱ་ན་ཙཻ་ཏྱ་སྟོ་ཏྲ། བོད་སྐད་དུ། གནས་ཆེན་པོ་བརྒྱད་ཀྱི་མཆོད་རྟེན་ལ་བསྟོད་པ། འཇམ་དཔལ་གཞོན་ནུར་གྱུར་པ་ལ་ཕྱག་འཚལ་ལོ། །འགྲོ་བའི་བླ་མ་གཅིག་པུ་ལུམྦཱིར་བལྟམས། །སེར་སྐྱའི་གྲོང་ཁྱེར་གཞི་རུ་གནས་པར་མཛད། །ཡོན་ཏན་\nརིན་ཆེན་བྱེ་བས་བརྒྱན་པ་ཡི། །བདེ་གཤེགས་མཆོད་རྟེན་རྣམས་ལ་ཕྱག་འཚལ་ལོ། །མ་ག་དྷཱ་ཡི་བྱང་ཆུབ་ཤིང་དྲུང་དུ། །ཆུ་བོ་ནཻ་རཉྫ་ན་ཞེས་བྱ་བའི། །འགྲམ་བཞུགས་མཆོད་རྟེན་ཡོན་ཏན་རྒྱ་ཆེ་བ། །བྱང་ཆུབ་རྟེན་དུ་གྱུར་ལ་ཕྱག་འཚལ་ལོ། །ཀ་ཤི་ཀ་ཡི་བཱ་རཱ་ཎ་སཱི་རུ། །ཆོས་ཀྱི་འཁོར་\nལོ་རྣམ་གྲོལ་རྨད་བྱུང་ནི། །ཉོན་མོངས་སྒྲིབ་པ་རྣམ་པར་གཅོད་མཛད་པ། །ཡེ་ཤེས་མཆོད་རྟེན་བཞི་ལ་ཕྱག་འཚལ་ལོ། །མཉན་དུ་ཡོད་པར་གཞན་སྟོབས་ཚར་བཅད་ནས། །ཛེ་ཏའི་ཚལ་དུ་ཆོ་འཕྲུལ་ཆེན་པོ་བསྟན། །ས་གསུམ་དགོངས་པ་མཆོག་ཏུ་བསྒྲུབ་མཛད་པ། །མུ་སྟེགས་\nཕམ་མཛད་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །གྲོང་ཁྱེར་དམ་པ་མཆོག་ནི་གསལ་ལྡན་དུ། །ལྷ་རྣམས་གནས་གཤེགས་བླ་ན་མེད་པར་བབས། །ཞབས་ལ་ཚངས་དབང་ཅོད་པན་གྱིས་མཆོད་པ། །སུམ་ཅུའི་ལྷས་མཆོད་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །དགེ་འདུན་དབྱེན་དུ་སྔར་གྱུར་ལས། །\nསྟོན་པའི་ཉན་ཐོས་རབ་མཐུན་པ། །རྒྱལ་པོའི་ཁབ་ཀྱི་འོད་མའི་ཚལ། །བྱམས་ངོས་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །སྐུ་ཚེ་འདུ་བྱེད་བཏང་བ་ལས། །སླར་ཡང་སྐུ་ཚེ་བྱིན་བརླབས་པ། །རྣམ་གྲོལ་ཡངས་པ་ཅན་གྱི་ནི། །བྱིན་བརླབས་མཆོད་རྟེན་ཕྱག་འཚལ་ལོ། །ཀུ་ཤའི་གྲོང་དུ་འགྲོ་བ་\n\nརྣམས། །དགེ་བ་ལ་ནི་སྦྱོར་མཛད་ཅིང་། །འགྲན་མེད་གྱད་གནས་ཟུང་གི་ཚལ། །མཆོད་རྟེན་མྱ་ངན་འདས་ཕྱག་འཚལ། །ཤཱཀྱ་ཐུབ་མཆོད་རྟེན་བརྒྱད་པོ་དག །ཕྱོགས་བཅུ་གཞན་དང་གཞན་རྣམས་ན། །བཞུགས་པའི་ཆོས་སྐུ་ཀུན་ལ་འདུད། །ཞི་ལ་རྟག་ཏུ་སྤྱིས་ཕྱག་\nའཚལ། །འདི་ལྟར་སྤྲོས་པ་ཀུན་བྲལ་དཔེ་མེད་རྟག་ཅིང་དག་པའི་ངོ་བོ་ཉིད། །སངས་རྒྱས་ཆོས་སྐུ་མཁའ་ལྟར་འགྲོ་བ་ལ་ཁྱབ་ཡང་དག་ཕྱག་འཚལ་བས། །བསོད་ནམས་གངས་རིའི་ཁ་དོག་ལྟར་དཀར་བདག་གི་རྒྱུད་ལ་གང་བསགས་པ། །དེས་ནི་སེམས་ཅན་མ་ལུས་ཏིང་འཛིན་བདེ་རྟོགས་བྱང་ཆུབ་\nཐོབ་པར་ཤོག །གནས་ཆེན་པོ་བརྒྱད་ཀྱི་མཆོད་རྟེན་ལ་བསྟོད་པ། སློབ་དཔོན་ཆེན་པོ་འཕགས་པ་ཀླུ་སྒྲུབ་ཀྱིས་མཛད་པ་རྫོགས་སོ།། ༄