What is the least resource intensive way to generate the luatex font cache for a new font?Using MinionPro for the main font and Fontspec for the monospaced fontHow to generate compounded diacritical fonts for Sanskrit with XeTeX and LuaTeX?What is the .ttf font for default LaTeX font?how to set font feature file for a specific font file and not the whole font shapeWhat is the default font for LaTeX?What is the best Math Font for use with Minion Pro font?What is the least invasive way to set the font for listings?LuaLatex setup a different font for numbers and the restMaking a new font family based on the default fontWhat is the correct way to make setmainfont take effect?

Why would five hundred and five be same as one?

Can I run 125kHz RF circuit on a breadboard?

What is this high flying aircraft over Pennsylvania?

Unable to disable Microsoft Store in domain environment

Why do Radio Buttons not fill the entire outer circle?

How to make money from a browser who sees 5 seconds into the future of any web page?

How to reduce predictors the right way for a logistic regression model

Given this phrasing in the lease, when should I pay my rent?

Sound waves in different octaves

Do you waste sorcery points if you try to apply metamagic to a spell from a scroll but fail to cast it?

Anime with legendary swords made from talismans and a man who could change them with a shattered body

Why didn’t Eve recognize the little cockroach as a living organism?

Why is participating in the European Parliamentary elections used as a threat?

In One Punch Man, is King actually weak?

What's the name of the logical fallacy where a debater extends a statement far beyond the original statement to make it true?

The Digit Triangles

Typing CO_2 easily

How to make a list of partial sums using forEach

Did I make a mistake by ccing email to boss to others?

How do I prevent inappropriate ads from appearing in my game?

Sigmoid with a slope but no asymptotes?

Do I have to know the General Relativity theory to understand the concept of inertial frame?

What does "tick" mean in this sentence?

Mimic lecturing on blackboard, facing audience



What is the least resource intensive way to generate the luatex font cache for a new font?


Using MinionPro for the main font and Fontspec for the monospaced fontHow to generate compounded diacritical fonts for Sanskrit with XeTeX and LuaTeX?What is the .ttf font for default LaTeX font?how to set font feature file for a specific font file and not the whole font shapeWhat is the default font for LaTeX?What is the best Math Font for use with Minion Pro font?What is the least invasive way to set the font for listings?LuaLatex setup a different font for numbers and the restMaking a new font family based on the default fontWhat is the correct way to make setmainfont take effect?













9















When a font is first used with lualatex, luaotfload does some magic to produce font cache files.



For large fonts (e.g., Noto Sans CJK) this can take a lot of time and a lot of memory.



I have an old computer (5 year old MacBook air with 4GB RAM) running Linux with a 4GB swap partition. The initial cache generation of this font can take more than 15 min and render my computer unusable. Sometimes I just run out of memory and the process is killed.



Let's say I want to use the font as such:



documentclassarticle
usepackagefontspec
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument


What is the least resource intensive way and/or fastest way to generate the required cache files?



At the moment, I quit everything (even X11) and run lualatex from the console, but it still takes a long time, and quitting everything is a bit of a pain.










share|improve this question

















  • 1





    That is a very good question, but I don't think you can do any better as you do now. Here is Hans' statement about this: mailman.ntg.nl/pipermail/ntg-context/2018/092703.html

    – Henri Menke
    Mar 16 at 7:49












  • xelatex might be an alternative if you don't need lua-specifics, just fontspec.

    – Joseph
    Mar 16 at 11:23











  • @Joseph, yes xelatex has no problems of course. Although I notice something curious with xelatex. I use the true type collection font: NotoSansCJK-Regular.ttc. When I run pdffonts on the the PDF file produced by xelatex it gives: ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Notice jp for Japanese instead of sc for Simplified Chinese as requested). I don't know where the error is though. I guess it xelatex could be embedding the right font from the ttc but with the wrong name.

    – David Purton
    Mar 16 at 11:38











  • As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the jp one. All the language specific fonts contain all glyphs and the right language seems to be automatically used by xelatex when you request a language specific font without manually specifying the Language= option of fontspec.

    – David Purton
    Mar 16 at 13:11















9















When a font is first used with lualatex, luaotfload does some magic to produce font cache files.



For large fonts (e.g., Noto Sans CJK) this can take a lot of time and a lot of memory.



I have an old computer (5 year old MacBook air with 4GB RAM) running Linux with a 4GB swap partition. The initial cache generation of this font can take more than 15 min and render my computer unusable. Sometimes I just run out of memory and the process is killed.



Let's say I want to use the font as such:



documentclassarticle
usepackagefontspec
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument


What is the least resource intensive way and/or fastest way to generate the required cache files?



At the moment, I quit everything (even X11) and run lualatex from the console, but it still takes a long time, and quitting everything is a bit of a pain.










share|improve this question

















  • 1





    That is a very good question, but I don't think you can do any better as you do now. Here is Hans' statement about this: mailman.ntg.nl/pipermail/ntg-context/2018/092703.html

    – Henri Menke
    Mar 16 at 7:49












  • xelatex might be an alternative if you don't need lua-specifics, just fontspec.

    – Joseph
    Mar 16 at 11:23











  • @Joseph, yes xelatex has no problems of course. Although I notice something curious with xelatex. I use the true type collection font: NotoSansCJK-Regular.ttc. When I run pdffonts on the the PDF file produced by xelatex it gives: ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Notice jp for Japanese instead of sc for Simplified Chinese as requested). I don't know where the error is though. I guess it xelatex could be embedding the right font from the ttc but with the wrong name.

    – David Purton
    Mar 16 at 11:38











  • As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the jp one. All the language specific fonts contain all glyphs and the right language seems to be automatically used by xelatex when you request a language specific font without manually specifying the Language= option of fontspec.

    – David Purton
    Mar 16 at 13:11













9












9








9


2






When a font is first used with lualatex, luaotfload does some magic to produce font cache files.



For large fonts (e.g., Noto Sans CJK) this can take a lot of time and a lot of memory.



I have an old computer (5 year old MacBook air with 4GB RAM) running Linux with a 4GB swap partition. The initial cache generation of this font can take more than 15 min and render my computer unusable. Sometimes I just run out of memory and the process is killed.



Let's say I want to use the font as such:



documentclassarticle
usepackagefontspec
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument


What is the least resource intensive way and/or fastest way to generate the required cache files?



At the moment, I quit everything (even X11) and run lualatex from the console, but it still takes a long time, and quitting everything is a bit of a pain.










share|improve this question














When a font is first used with lualatex, luaotfload does some magic to produce font cache files.



For large fonts (e.g., Noto Sans CJK) this can take a lot of time and a lot of memory.



I have an old computer (5 year old MacBook air with 4GB RAM) running Linux with a 4GB swap partition. The initial cache generation of this font can take more than 15 min and render my computer unusable. Sometimes I just run out of memory and the process is killed.



Let's say I want to use the font as such:



documentclassarticle
usepackagefontspec
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument


What is the least resource intensive way and/or fastest way to generate the required cache files?



At the moment, I quit everything (even X11) and run lualatex from the console, but it still takes a long time, and quitting everything is a bit of a pain.







fonts luatex fontspec luaotfload






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 16 at 4:44









David PurtonDavid Purton

10.8k2940




10.8k2940







  • 1





    That is a very good question, but I don't think you can do any better as you do now. Here is Hans' statement about this: mailman.ntg.nl/pipermail/ntg-context/2018/092703.html

    – Henri Menke
    Mar 16 at 7:49












  • xelatex might be an alternative if you don't need lua-specifics, just fontspec.

    – Joseph
    Mar 16 at 11:23











  • @Joseph, yes xelatex has no problems of course. Although I notice something curious with xelatex. I use the true type collection font: NotoSansCJK-Regular.ttc. When I run pdffonts on the the PDF file produced by xelatex it gives: ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Notice jp for Japanese instead of sc for Simplified Chinese as requested). I don't know where the error is though. I guess it xelatex could be embedding the right font from the ttc but with the wrong name.

    – David Purton
    Mar 16 at 11:38











  • As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the jp one. All the language specific fonts contain all glyphs and the right language seems to be automatically used by xelatex when you request a language specific font without manually specifying the Language= option of fontspec.

    – David Purton
    Mar 16 at 13:11












  • 1





    That is a very good question, but I don't think you can do any better as you do now. Here is Hans' statement about this: mailman.ntg.nl/pipermail/ntg-context/2018/092703.html

    – Henri Menke
    Mar 16 at 7:49












  • xelatex might be an alternative if you don't need lua-specifics, just fontspec.

    – Joseph
    Mar 16 at 11:23











  • @Joseph, yes xelatex has no problems of course. Although I notice something curious with xelatex. I use the true type collection font: NotoSansCJK-Regular.ttc. When I run pdffonts on the the PDF file produced by xelatex it gives: ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Notice jp for Japanese instead of sc for Simplified Chinese as requested). I don't know where the error is though. I guess it xelatex could be embedding the right font from the ttc but with the wrong name.

    – David Purton
    Mar 16 at 11:38











  • As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the jp one. All the language specific fonts contain all glyphs and the right language seems to be automatically used by xelatex when you request a language specific font without manually specifying the Language= option of fontspec.

    – David Purton
    Mar 16 at 13:11







1




1





That is a very good question, but I don't think you can do any better as you do now. Here is Hans' statement about this: mailman.ntg.nl/pipermail/ntg-context/2018/092703.html

– Henri Menke
Mar 16 at 7:49






That is a very good question, but I don't think you can do any better as you do now. Here is Hans' statement about this: mailman.ntg.nl/pipermail/ntg-context/2018/092703.html

– Henri Menke
Mar 16 at 7:49














xelatex might be an alternative if you don't need lua-specifics, just fontspec.

– Joseph
Mar 16 at 11:23





xelatex might be an alternative if you don't need lua-specifics, just fontspec.

– Joseph
Mar 16 at 11:23













@Joseph, yes xelatex has no problems of course. Although I notice something curious with xelatex. I use the true type collection font: NotoSansCJK-Regular.ttc. When I run pdffonts on the the PDF file produced by xelatex it gives: ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Notice jp for Japanese instead of sc for Simplified Chinese as requested). I don't know where the error is though. I guess it xelatex could be embedding the right font from the ttc but with the wrong name.

– David Purton
Mar 16 at 11:38





@Joseph, yes xelatex has no problems of course. Although I notice something curious with xelatex. I use the true type collection font: NotoSansCJK-Regular.ttc. When I run pdffonts on the the PDF file produced by xelatex it gives: ROREZJ+NotoSansCJKjp-Regular-Identity-H. (Notice jp for Japanese instead of sc for Simplified Chinese as requested). I don't know where the error is though. I guess it xelatex could be embedding the right font from the ttc but with the wrong name.

– David Purton
Mar 16 at 11:38













As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the jp one. All the language specific fonts contain all glyphs and the right language seems to be automatically used by xelatex when you request a language specific font without manually specifying the Language= option of fontspec.

– David Purton
Mar 16 at 13:11





As an addition to my previous comment: I'm pretty sure the output is correct even though the font reported is always the jp one. All the language specific fonts contain all glyphs and the right language seems to be automatically used by xelatex when you request a language specific font without manually specifying the Language= option of fontspec.

– David Purton
Mar 16 at 13:11










1 Answer
1






active

oldest

votes


















9














You can do as proposed in section 9.2.1 “Trimming fonts“ in Fonts out of ConTeXt and remove all the glyph names in the font.



enter image description here



Adapted to LaTeX and your example:



documentclassarticle
usepackagefontspec,luacode
beginluacode*


fonts.handlers.otf.readers.registerextender 
name = "remove names from Noto Sans CJK SC",
action = function(fontdata)
if string.match(fontdata.metadata.fullname, "Noto Sans CJK SC") then
texio.write_nl("Trimming font " .. fontdata.metadata.fullname)
for k, v in next, fontdata.descriptions do
v.name = nil
end
end
end





endluacode*
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument





share|improve this answer























  • Can this solution be problematic in some cases?

    – Paul Gaborit
    Mar 16 at 8:21











  • @PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.

    – Henri Menke
    Mar 16 at 8:28












  • Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something.

    – David Purton
    Mar 16 at 10:57










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "85"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f479744%2fwhat-is-the-least-resource-intensive-way-to-generate-the-luatex-font-cache-for-a%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









9














You can do as proposed in section 9.2.1 “Trimming fonts“ in Fonts out of ConTeXt and remove all the glyph names in the font.



enter image description here



Adapted to LaTeX and your example:



documentclassarticle
usepackagefontspec,luacode
beginluacode*


fonts.handlers.otf.readers.registerextender 
name = "remove names from Noto Sans CJK SC",
action = function(fontdata)
if string.match(fontdata.metadata.fullname, "Noto Sans CJK SC") then
texio.write_nl("Trimming font " .. fontdata.metadata.fullname)
for k, v in next, fontdata.descriptions do
v.name = nil
end
end
end





endluacode*
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument





share|improve this answer























  • Can this solution be problematic in some cases?

    – Paul Gaborit
    Mar 16 at 8:21











  • @PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.

    – Henri Menke
    Mar 16 at 8:28












  • Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something.

    – David Purton
    Mar 16 at 10:57















9














You can do as proposed in section 9.2.1 “Trimming fonts“ in Fonts out of ConTeXt and remove all the glyph names in the font.



enter image description here



Adapted to LaTeX and your example:



documentclassarticle
usepackagefontspec,luacode
beginluacode*


fonts.handlers.otf.readers.registerextender 
name = "remove names from Noto Sans CJK SC",
action = function(fontdata)
if string.match(fontdata.metadata.fullname, "Noto Sans CJK SC") then
texio.write_nl("Trimming font " .. fontdata.metadata.fullname)
for k, v in next, fontdata.descriptions do
v.name = nil
end
end
end





endluacode*
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument





share|improve this answer























  • Can this solution be problematic in some cases?

    – Paul Gaborit
    Mar 16 at 8:21











  • @PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.

    – Henri Menke
    Mar 16 at 8:28












  • Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something.

    – David Purton
    Mar 16 at 10:57













9












9








9







You can do as proposed in section 9.2.1 “Trimming fonts“ in Fonts out of ConTeXt and remove all the glyph names in the font.



enter image description here



Adapted to LaTeX and your example:



documentclassarticle
usepackagefontspec,luacode
beginluacode*


fonts.handlers.otf.readers.registerextender 
name = "remove names from Noto Sans CJK SC",
action = function(fontdata)
if string.match(fontdata.metadata.fullname, "Noto Sans CJK SC") then
texio.write_nl("Trimming font " .. fontdata.metadata.fullname)
for k, v in next, fontdata.descriptions do
v.name = nil
end
end
end





endluacode*
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument





share|improve this answer













You can do as proposed in section 9.2.1 “Trimming fonts“ in Fonts out of ConTeXt and remove all the glyph names in the font.



enter image description here



Adapted to LaTeX and your example:



documentclassarticle
usepackagefontspec,luacode
beginluacode*


fonts.handlers.otf.readers.registerextender 
name = "remove names from Noto Sans CJK SC",
action = function(fontdata)
if string.match(fontdata.metadata.fullname, "Noto Sans CJK SC") then
texio.write_nl("Trimming font " .. fontdata.metadata.fullname)
for k, v in next, fontdata.descriptions do
v.name = nil
end
end
end





endluacode*
setmainfont[Script=CJK,Language=Chinese Simplified]Noto Sans CJK SC
begindocument
中文
enddocument






share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 16 at 8:08









Henri MenkeHenri Menke

77k8169283




77k8169283












  • Can this solution be problematic in some cases?

    – Paul Gaborit
    Mar 16 at 8:21











  • @PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.

    – Henri Menke
    Mar 16 at 8:28












  • Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something.

    – David Purton
    Mar 16 at 10:57

















  • Can this solution be problematic in some cases?

    – Paul Gaborit
    Mar 16 at 8:21











  • @PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.

    – Henri Menke
    Mar 16 at 8:28












  • Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something.

    – David Purton
    Mar 16 at 10:57
















Can this solution be problematic in some cases?

– Paul Gaborit
Mar 16 at 8:21





Can this solution be problematic in some cases?

– Paul Gaborit
Mar 16 at 8:21













@PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.

– Henri Menke
Mar 16 at 8:28






@PaulGaborit Yes, anything that wants to access glyphs by name won't work. In ConTeXt there is getnamedglyphdirect which will break. I don't think there is anything like this in LaTeX. Also those name lookups are not very efficient.

– Henri Menke
Mar 16 at 8:28














Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something.

– David Purton
Mar 16 at 10:57





Well, I did manage to successfully generate cache files for Source Han Serif (regular, bold). Chromium was killed to compensate, used up all my RAM, and took half an hour! But it did work. Without your lua code I didn't manage to complete the compile without it being killed. So that's something.

– David Purton
Mar 16 at 10:57

















draft saved

draft discarded
















































Thanks for contributing an answer to TeX - LaTeX Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f479744%2fwhat-is-the-least-resource-intensive-way-to-generate-the-luatex-font-cache-for-a%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Masuk log Menu navigasi

Identifying “long and narrow” polygons in with PostGISlength and width of polygonWhy postgis st_overlaps reports Qgis' “avoid intersections” generated polygon as overlapping with others?Adjusting polygons to boundary and filling holesDrawing polygons with fixed area?How to remove spikes in Polygons with PostGISDeleting sliver polygons after difference operation in QGIS?Snapping boundaries in PostGISSplit polygon into parts adding attributes based on underlying polygon in QGISSplitting overlap between polygons and assign to nearest polygon using PostGIS?Expanding polygons and clipping at midpoint?Removing Intersection of Buffers in Same Layers

Старые Смолеговицы Содержание История | География | Демография | Достопримечательности | Примечания | НавигацияHGЯOLHGЯOL41 206 832 01641 606 406 141Административно-территориальное деление Ленинградской области«Переписная оброчная книга Водской пятины 1500 года», С. 793«Карта Ингерманландии: Ивангорода, Яма, Копорья, Нотеборга», по материалам 1676 г.«Генеральная карта провинции Ингерманландии» Э. Белинга и А. Андерсина, 1704 г., составлена по материалам 1678 г.«Географический чертёж над Ижорскою землей со своими городами» Адриана Шонбека 1705 г.Новая и достоверная всей Ингерманландии ланткарта. Грав. А. Ростовцев. СПб., 1727 г.Топографическая карта Санкт-Петербургской губернии. 5-и верстка. Шуберт. 1834 г.Описание Санкт-Петербургской губернии по уездам и станамСпецкарта западной части России Ф. Ф. Шуберта. 1844 г.Алфавитный список селений по уездам и станам С.-Петербургской губернииСписки населённых мест Российской Империи, составленные и издаваемые центральным статистическим комитетом министерства внутренних дел. XXXVII. Санкт-Петербургская губерния. По состоянию на 1862 год. СПб. 1864. С. 203Материалы по статистике народного хозяйства в С.-Петербургской губернии. Вып. IX. Частновладельческое хозяйство в Ямбургском уезде. СПб, 1888, С. 146, С. 2, 7, 54Положение о гербе муниципального образования Курское сельское поселениеСправочник истории административно-территориального деления Ленинградской области.Топографическая карта Ленинградской области, квадрат О-35-23-В (Хотыницы), 1930 г.АрхивированоАдминистративно-территориальное деление Ленинградской области. — Л., 1933, С. 27, 198АрхивированоАдминистративно-экономический справочник по Ленинградской области. — Л., 1936, с. 219АрхивированоАдминистративно-территориальное деление Ленинградской области. — Л., 1966, с. 175АрхивированоАдминистративно-территориальное деление Ленинградской области. — Лениздат, 1973, С. 180АрхивированоАдминистративно-территориальное деление Ленинградской области. — Лениздат, 1990, ISBN 5-289-00612-5, С. 38АрхивированоАдминистративно-территориальное деление Ленинградской области. — СПб., 2007, с. 60АрхивированоКоряков Юрий База данных «Этно-языковой состав населённых пунктов России». Ленинградская область.Административно-территориальное деление Ленинградской области. — СПб, 1997, ISBN 5-86153-055-6, С. 41АрхивированоКультовый комплекс Старые Смолеговицы // Электронная энциклопедия ЭрмитажаПроблемы выявления, изучения и сохранения культовых комплексов с каменными крестами: по материалам работ 2016-2017 гг. в Ленинградской области