0
366 次瀏覽

Hello,

I am writing as a representative of a small task team assigned to review proposals for what becomes a formal update to USFM and USX (3.0). The current documentation for the 3.0 proposal includes a mix of new markup proposals, changes / corrections to the definitions for marker validity (i.e. the usfm.sty stylesheet rules, and USX schema), and proposals for deprecating some existing markup.

Two of the more notable additions are 1) a proposed syntax for adding descriptive attributes to words (character level markers) in USFM / USX and 2) a proposed syntax for defining linking in USFM / USX.

The 3.0 proposal is an attempt to summarize collected input from users, and to provide standard solutions in USFM and USX for various archiving and publication needs (especially in light of digital).

It would be helpful at this time to have a somewhat larger body of interested people review the current documentation, and comment. Input might come from users or tool developers. This will help to ensure that important needs are not missed or inadequately addressed - but is not intending to imply that all new requests would be immediately included in USFM / USX 3.0 (there’s always 3.1!)

If you would like to engage in reviewing / commenting on the current proposal documentation, please contact me directly off-list, and I will be able to share the necessary information with you.

Thank you.

jmkla
[Email Removed]

舊文章 - 以原文顯示
Paratext [Expert]
(290 點) 提出
| 366 次瀏覽

2 個回答

0
最佳回答

Is there a way that any of us can suggest additions to USFM? For example, I had a couple of ideas recently …

One is a marker to quote text literally – text that would otherwise be interpreted as a marker or special character (e.g. when you want a project to contain the text “http://…”) – see my brief discussion of it here: Guide: File > Print Draft .

Another would be a clause-divider marker: in the language I work in, we often have long sentences with no commas. In a SAB-built* app with text highlighting at a phrase level during audio playback, it would be nice to be able to divide a long sentence into two or three with a marker that aeneas would treat as punctuation. Though I guess we could use a hidden space, and tell aeneas that this is a punctuation character; or, if we wanted a visible character, we could use, say, a hash (#), and then have PrintDraftChanges.txt remove hashes at publication time.

But if we had a marker for this, we might also have a marker for no-clause-divide: our language also sometimes has sentences with far too many commas, and that looks silly when an SAB app reads the text. With this marker, you could mark a comma or other punctuation mark so that it is ignored by aeneas.

* Scripture App Builder
aeneas is a program that automatically calculates the timings of the punctuation marks that you select. It was developed for use with SAB. The same markers I’m suggesting could also be used by teams that mark the timings manually: in this case the punctuation marks (and, in my suggestion, also markers) divide up the script that SAB outputs, and which aids the person listening to the audio.

舊文章 - 以原文顯示
(1.4k 點) 提出
已重新顯示

wdavidhj, (others)

You can engage with the USFM issues backlog in Github, here:

The current open issues / comments / ideas are here: https://github.com/ubsicap/usfm/issues

The items intended in 3.0.0 are here: https://github.com/ubsicap/usfm/milestone/2
(there are some open items, some of which relate to need for adjustments to documentation or stylesheets; a few new items yet).

3.0.0 support in Paratext will not happen officially until PT 8.1. Some items in USFM 3 will require more and less support from the editor – and it may not all receive a final polished treatment, but will work with checking tools. Items such as Ruby support for CJK texts will have some substantial UI / editor support in Paratext.

The documentation is built from this repository, and the current version can be found at.
https://ubsicap.github.io/usfm/

jmkla

舊文章 - 以原文顯示
0

I see that Paratext 8.0.83.1 still comes with USFM 2.502. Is that still the latest approved USFM standard? Is USFM 3.0.0 still just a proposal?

舊文章 - 以原文顯示
(346 點) 提出

相關問題

+5
1 個回答 251 次瀏覽
Hello, I am looking for an offline version of USFM 3.0. Is there anyway to get a PDF version of USFM 3.0 that is found ... to make 3.0 available in PDF as well? Cheers - pbtpng.it
pbtpng.it 142 提出 已提問 5月 13, 2019
0
2 個回答 47 次瀏覽
我需要將 USX 檔案轉換為 USFM 我看到 Paratext 有一個選項可以進行反向操作,但找不到將 USX 轉換為 USFM 的選項 我需要這樣做,是因為 Proskomma(用於 Scripture App Builder 建置 PWA)拒 ... 卷,理由是它們不符合標準格式 我希望將它們轉換為 USFM 後,Proskomma 處理起來會更容易
yeti 109 提出 已提問 3月 19
+1
6 個回答 820 次瀏覽
有人知道一個將 USFM 格式轉換為 USX(或其他任何 xml 變體)的命令列工具嗎? 我想寫一個腳本,從不同的專案中抓取幾個不同的 .sfm 檔案並批量轉換它們 使用內建的 Tools->Advanced->Export Project ... usfm2usfx.exe 工具,但無法使其工作,但如果人們說那是最佳選擇,我可以嘗試弄清楚哪裡出了問題
mnjames 1.9k 提出 已提問 8月 30, 2018
0
2 個回答 236 次瀏覽
In the USX export file from Paratext, for certain references, the transformation adds an extra - in the tag. ... bug in the USX transformation. Any help would be appreciated.
anon753074 109 提出 已提問 4月 24, 2020
0
1 個回答 249 次瀏覽
We very much appreciate the way PT8 manges hyphenation data. I might have mentioned that our entire language project ( ... can be. So please lift the one-character-limitation.
Tim 934 提出 已提問 3月 5, 2019
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
But if we walk in the light, as he is in the light, we have fellowship with one another, and the blood of Jesus, his Son, purifies us from all sin.
1 John 1:7
3,047 個問題
6,007 個回答
5,671 則評論
2,027 位使用者